summaryrefslogtreecommitdiffstats
path: root/vpp-api
diff options
context:
space:
mode:
authorChris Luke <chrisy@flirble.org>2016-04-25 14:26:55 -0400
committerDave Barach <openvpp@barachs.net>2016-04-28 11:37:30 +0000
commit194ebc58b6e362c7cc950ba2386567bfdbfbab55 (patch)
tree927dd4fe75586d31b1adf2a2e12c47228db0dddf /vpp-api
parent473bf23be85e861f95d69992b09b0b7d7a6efa2e (diff)
Track number of ethernet vlans in a frame
Adds flags to the packet buffer to track the number of VLANs in the current Ethernet frame. We use two bits to signify 0, 1 or 2 VLANs. The value 3 signififies an unknown quantity of VLANs, which includes "three or more" which is not widely supported. We place the bits in the vlib_buffer section; that is not the opaque section, so that all subordinate nodes can use it. For background, see the discussion thread at https://lists.fd.io/pipermail/vpp-dev/2016-March/000354.html The helper macro ethernet_buffer_header_size(buffer) uses these bits stored in "buffer" to calculate the Ethernet header size. The macro ethernet_buffer_set_vlan_count(buffer, count) sets the appropriate bit values based on the number in "count". By current frame we are referring to the case where a packet that arrives from the wire is carrying an encapsulated Ethernet packet. Once decapsulated that inner packet becomes the current frame. There are two places where this value is set; For most Ethernet frames this will be in the "ethernet-input" node when that node parses the Ethernet header. The second place is whenever vnet_update_l2_len() is used to update the layer 2 opaque data. Typically this function is used by nodes just before they send a packet into l2-input. These bits are zeroed in vlib_buffer_init_for_free_list() meaning that wherever the buffer comes from they have a reasonable value (eg, if ip4/ip6 generates the packet.) Primarily this VLAN counter is used by nodes below "ethernet- input" and "l2-input" to determine where the start of the current Ethernet header is. There is opaque data set by "ethernet-input" storing the offset of the current Ethernet header but, since this is opaque, it's not usable by downstream nodes. Previously several nodes have made assumptions regarding the location of the Ethernet header, including that it is always at the start of the packet buffer (incorrect when we have encapsulated packets) or that it is exactly sizeof(ethernet_header_t) away (incorrect when we have VLAN tags.) One notable case where this functionality is required is in ip6_neighbor when it generates a response to a received neighbor soliciation request; it reuses the incoming Ethernet header in-situ and thus needs to reliably know where that header begins. Also, at the suggestion of Dave Barach, this patch removes definition of HGSHM bits in the buffer flags since they are unused and unlikely to ever be. Change-Id: I00e4b9ced5ef814a776020c395d1774aba6185b3 Signed-off-by: Chris Luke <chrisy@flirble.org>
Diffstat (limited to 'vpp-api')
0 files changed, 0 insertions, 0 deletions