On Nov 27, 2018, at 1:50 PM, Dave Barach (dbarach) <dbar...@cisco.com> wrote:
> After thinking about some of your feedback, I decided to move most of the
> work back to the vpp side where it probably belonged in the first place.
...
> Anyhow, here's what I implemented. Take a look AYC and let me know what you
> think.
>
> VPP graph dispatch trace record description.
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Major Version | Minor Version | NStrings | ProtoHint |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Buffer index (big endian FWIW) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> + VPP graph node name ... ... | NULL octet |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Buffer Metadata ASCII string ... ... | NULL octet |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Buffer Opaque ASCII string ... ... | NULL octet |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Buffer Opaque 2 ASCII string ... ... | NULL octet |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | VPP ASCII packet trace (if NStrings > 4) ... | NULL octet |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Packet data (up to 16K) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Graph dispatch records comprise a version stamp, an indication of how many
> NULL-terminated strings will follow the record header, and a
> protocol hint.
>
> The buffer index allows downstream consumers of these data to easily
> filter/track single packets as they traverse the forwarding
> graph.
So does that mean that there might be multiple records in the file for the same
packet, with all records for the same packet having the same buffer index?
> FWIW, the 32-bit buffer index is stored in big endian format.
If it's only to be used for matching purposes, presumably that means that
1) its value has no numerical significance;
2) the only comparisons done on that value are equality comparisons;
so it could be treated as a 4-byte opaque value, in which case the byte order
doesn't matter.
> As of this writing, major version = 1, minor version = 0; Nstrings will be
> either 4 or 5.
So smaller or larger values MAY (and probably SHOULD) be treated as errors.
> Here is the current set of protocol hints:
>
> typedef enum
> {
> VLIB_NODE_PROTO_HINT_NONE = 0,
> VLIB_NODE_PROTO_HINT_ETHERNET,
> VLIB_NODE_PROTO_HINT_IP4,
> VLIB_NODE_PROTO_HINT_IP6,
> VLIB_NODE_PROTO_HINT_TCP,
> VLIB_NODE_PROTO_HINT_UDP,
> VLIB_NODE_N_PROTO_HINTS,
> } vlib_node_proto_hint_t;
So a dissector MAY use that to indicate what the next protocol is.
> Example: VLIB_NODE_PROTO_HINT_IP6 means that the first octet of packet data
> SHOULD be 0x60, and should begin an ipv6 packet header.
That's SHOULD, not MUST; is there anything else a dissector should do other
than use the protocol hint for handoff?
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
