Hello experts,
There appears to be a small nit in this function, though it upsets some
calculations in my plugin which follows ip_input in the case of BDs.
static_always_inline u32
38 l2_to_bvi (vlib_main_t * vlib_main,
39 vnet_main_t * vnet_main,
40 vlib_buffer_t * b0,
41 u32 bvi_sw_if_index, next_by_ethertype_t * l3_next, u16 * next0)
42 {
43 /* Perform L3 my-mac filter */
44 ethernet_header_t *e0 = vlib_buffer_get_current (b0);
45 if (!ethernet_address_cast (e0->dst_address))
46 {
52
53 /* Save L2 header position which may be changed due to packet replication
*/
54 vnet_buffer (b0)->l2_hdr_offset = b0->current_data;
55
56 /* Strip L2 header */
57 u8 l2_len = vnet_buffer (b0)->l2.l2_len;
58 vlib_buffer_advance (b0, l2_len); <<<<<<<<<<<<<< When we
do this, should we also do < l2.l2_len -= l2_len. > ??
59
60 u8 *l3h = vlib_buffer_get_current (b0);
61 u16 ethertype = clib_net_to_host_u16 (*(u16 *) (l3h - 2));
62
My plugin tries to get IP header later using u8 *l3h0 = (u8 *) h0 + vnet_buffer
(b[0])->l2.l2_len; So this fails in the BD BVI case, but works all right for
routed sub-interfaces
Should I always rather use (b[0])->l3 ?? Is there a safer way to find out, if
a packet has L2 header stripped off , and starts from L3 header directly.
Regards,
Milan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12587): https://lists.fd.io/g/vpp-dev/message/12587
Mute This Topic: https://lists.fd.io/mt/30504309/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
