aboutsummaryrefslogtreecommitdiffstats
path: root/docs/gettingstarted/developers/vnet.md
diff options
context:
space:
mode:
authorDave Barach <dave@barachs.net>2019-01-17 09:30:43 -0500
committerDave Barach <dave@barachs.net>2019-01-17 09:31:00 -0500
commit1d052d2ef211c1dc5cc1f11b84feded90e1b5b27 (patch)
tree8a033391de5ee6f40bd0f00bbee290c8f99f834a /docs/gettingstarted/developers/vnet.md
parenta704f5b2a97346eaaeec466cda6169406a313490 (diff)
DOC ONLY: wireshark dissector upstreamed
Remove the last remnant from extra/wireshark, update the Sphinx docs Change-Id: I5886557f17192475c03fcb0dfde581e1e63cea5c Signed-off-by: Dave Barach <dave@barachs.net>
Diffstat (limited to 'docs/gettingstarted/developers/vnet.md')
-rw-r--r--docs/gettingstarted/developers/vnet.md57
1 files changed, 28 insertions, 29 deletions
diff --git a/docs/gettingstarted/developers/vnet.md b/docs/gettingstarted/developers/vnet.md
index 092da1a28a6..d8d9a3b4fec 100644
--- a/docs/gettingstarted/developers/vnet.md
+++ b/docs/gettingstarted/developers/vnet.md
@@ -54,16 +54,16 @@ units to convert buffer indices to buffer pointers:
n_left_from = frame->n_vectors;
from = vlib_frame_vector_args (frame);
- /*
- * Convert up to VLIB_FRAME_SIZE indices in "from" to
+ /*
+ * Convert up to VLIB_FRAME_SIZE indices in "from" to
* buffer pointers in bufs[]
*/
vlib_get_buffers (vm, from, bufs, n_left_from);
b = bufs;
next = nexts;
- /*
- * While we have at least 4 vector elements (pkts) to process..
+ /*
+ * While we have at least 4 vector elements (pkts) to process..
*/
while (n_left_from >= 4)
{
@@ -76,7 +76,7 @@ units to convert buffer indices to buffer pointers:
vlib_prefetch_buffer_header (b[7], STORE);
}
- /*
+ /*
* $$$ Process 4x packets right here...
* set next[0..3] to send the packets where they need to go
*/
@@ -91,12 +91,12 @@ units to convert buffer indices to buffer pointers:
next += 4;
n_left_from -= 4;
}
- /*
+ /*
* Clean up 0...3 remaining packets at the end of the incoming frame
*/
while (n_left_from > 0)
{
- /*
+ /*
* $$$ Process one packet right here...
* set next[0..3] to send the packets where they need to go
*/
@@ -117,7 +117,7 @@ units to convert buffer indices to buffer pointers:
vlib_buffer_enqueue_to_next (vm, node, from, nexts, frame->n_vectors);
return frame->n_vectors;
- }
+ }
```
Given a packet processing task to implement, it pays to scout around
@@ -150,7 +150,7 @@ tcp_get_free_buffer_index(...) for an example.
The following example shows the **main points**, but is not to be
blindly cut-'n-pasted.
-```c
+```c
u32 bi0;
vlib_buffer_t *b0;
ip4_header_t *ip;
@@ -170,7 +170,7 @@ blindly cut-'n-pasted.
/* At this point b0->current_data = 0, b0->current_length = 0 */
- /*
+ /*
* Copy data into the buffer. This example ASSUMES that data will fit
* in a single buffer, and is e.g. an ip4 packet.
*/
@@ -179,7 +179,7 @@ blindly cut-'n-pasted.
clib_memcpy (b0->data, data, vec_len (data));
b0->current_length = vec_len (data);
}
- else
+ else
{
/* OR, build a udp-ip packet (for example) */
ip = vlib_buffer_get_current (b0);
@@ -204,7 +204,7 @@ blindly cut-'n-pasted.
udp->checksum = ip4_tcp_udp_compute_checksum (vm, b0, ip);
if (udp->checksum == 0)
udp->checksum = 0xffff;
- }
+ }
b0->current_length = vec_len (sizeof (*ip) + sizeof (*udp) +
vec_len (udp_data));
@@ -217,7 +217,7 @@ blindly cut-'n-pasted.
/* Use the default FIB index for tx lookup. Set non-zero to use another fib */
vnet_buffer (b0)->sw_if_index[VLIB_TX] = 0;
-```
+```
If your use-case calls for large packet transmission, use
vlib_buffer_chain_append_data_with_alloc(...) to create the requisite
@@ -239,8 +239,8 @@ indices, and dispatch the frame using vlib_put_frame_to_node(...).
for (i = 0; i < vec_len (buffer_indices_to_send); i++)
to_next[i] = buffer_indices_to_send[i];
- vlib_put_frame_to_node (vm, ip4_lookup_node_index, f);
-```
+ vlib_put_frame_to_node (vm, ip4_lookup_node_index, f);
+```
It is inefficient to allocate and schedule single packet frames.
That's typical in case you need to send one packet per second, but
@@ -282,7 +282,7 @@ Here's a simple example:
s = format (s, "My trace data was: %d", t-><whatever>);
return s;
- }
+ }
```
The trace framework hands the per-node format function the data it
@@ -381,17 +381,17 @@ To save the pcap trace, e.g. in /tmp/dispatch.pcap:
```
pcap dispatch trace off
-```
+```
### Wireshark dissection of dispatch pcap traces
It almost goes without saying that we built a companion wireshark
-dissector to display these traces. As of this writing, we're in the
-process of trying to upstream the wireshark dissector.
+dissector to display these traces. As of this writing, we have
+upstreamed the wireshark dissector.
-Until we manage to upstream the wireshark dissector, please see the
-"How to build a vpp dispatch trace aware Wireshark" page for build
-info, and/or take a look at .../extras/wireshark.
+Since it will be a while before wireshark/master/latest makes it into
+all of the popular Linux distros, please see the "How to build a vpp
+dispatch trace aware Wireshark" page for build info.
Here is a sample packet dissection, with some fields omitted for
clarity. The point is that the wireshark dissector accurately
@@ -406,15 +406,15 @@ node in question.
BufferIndex: 0x00036663
NodeName: ethernet-input
VPP Buffer Metadata
- Metadata: flags:
+ Metadata: flags:
Metadata: current_data: 0, current_length: 102
Metadata: current_config_index: 0, flow_id: 0, next_buffer: 0
Metadata: error: 0, n_add_refs: 0, buffer_pool_index: 0
Metadata: trace_index: 0, recycle_count: 0, len_not_first_buf: 0
Metadata: free_list_index: 0
- Metadata:
+ Metadata:
VPP Buffer Opaque
- Opaque: raw: 00000007 ffffffff 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
+ Opaque: raw: 00000007 ffffffff 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Opaque: sw_if_index[VLIB_RX]: 7, sw_if_index[VLIB_TX]: -1
Opaque: L2 offset 0, L3 offset 0, L4 offset 0, feature arc index 0
Opaque: ip.adj_index[VLIB_RX]: 0, ip.adj_index[VLIB_TX]: 0
@@ -443,14 +443,14 @@ node in question.
Opaque: sctp.connection_index: 0, sctp.sid: 0, sctp.ssn: 0, sctp.tsn: 0, sctp.hdr_offset: 0
Opaque: sctp.data_offset: 0, sctp.data_len: 0, sctp.subconn_idx: 0, sctp.flags: 0x0
Opaque: snat.flags: 0x0
- Opaque:
+ Opaque:
VPP Buffer Opaque2
- Opaque2: raw: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
+ Opaque2: raw: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Opaque2: qos.bits: 0, qos.source: 0
Opaque2: loop_counter: 0
Opaque2: gbp.flags: 0, gbp.src_epg: 0
Opaque2: pg_replay_timestamp: 0
- Opaque2:
+ Opaque2:
Ethernet II, Src: 06:d6:01:41:3b:92 (06:d6:01:41:3b:92), Dst: IntelCor_3d:f6 Transmission Control Protocol, Src Port: 22432, Dst Port: 54084, Seq: 1, Ack: 1, Len: 36
Source Port: 22432
Destination Port: 54084
@@ -472,4 +472,3 @@ metadata changes, header checksum changes, and so forth.
This should be of significant value when developing new vpp graph
nodes. If new code mispositions b->current_data, it will be completely
obvious from looking at the dispatch trace in wireshark.
-