Re: Request for a new LINKTYPE_/DLT_ type.

[Guy Harris <gharris () sonic net>]

On Nov 27, 2018, at 1:50 PM, Dave Barach (dbarach) <dbarach () 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