Many NICs today does VLAN acceleration by delivering the VLAN TCI in
the RX descriptor, and stripping/starting the packet-data after the
VLAN header.

For XDP this special case handling for VLANs is annoying, and it
would also be annoying if we need to reserve a meta-data field for
this.

On the IOvisor call (June 1st 2016) is was argued that the VLAN header
should be part of normal packet. 1) either by disabling VLAN accel on
the NIC, or 2) by reconstructing the VLAN header (if needed) as
XDP/eBPF prog could be passed the VLAN TCI info as an argument.

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer

On 06/02/16 at 11:14am, Jesper Dangaard Brouer via iovisor-dev wrote:

Many NICs today does VLAN acceleration by delivering the VLAN TCI in
the RX descriptor, and stripping/starting the packet-data after the
VLAN header.

For XDP this special case handling for VLANs is annoying, and it
would also be annoying if we need to reserve a meta-data field for
this.

On the IOvisor call (June 1st 2016) is was argued that the VLAN header
should be part of normal packet. 1) either by disabling VLAN accel on
the NIC, or 2) by reconstructing the VLAN header (if needed) as
XDP/eBPF prog could be passed the VLAN TCI info as an argument.

I see little value in enabling VLAN acceleration in an XDP
environment. A VLAN header would be parsed or constructed with
BPF instructions. Any offload of VLAN parsing or constructions
should be done by offloading the BPF program itself.