RFC : VLAN vs. packet socket inconsistencies
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest4 patches 6 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | : vlan: Don't store VLAN tag in cbinclude/ include/ net/ | +13 | 0 replies | |
| 2/4 | : vlan: deliver packets received with VLAN acceleration to network tapsinclude/ net/ net/ | +32 | 0 replies | |
| 3/4 | : packet: Store VLAN tag in auxillary data | +0 | 1 reply | |
| 4/4 | : libpcap: reconstruct VLAN header from auxdatapcap-linux.c | +60 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 00/04]: VLAN vs. packet socket inconsistencies
There are currently a number of inconsistencies when using VLANs with VLAN acceleration and packet sockets:
1) With hardware tagging, outgoing packets are visible without the VLAN header, while with software tagging the full VLAN header is visible
2) With hardware stripping, incoming packets for locally configured VLANs appear on the VLAN device without being visible on the underlying device. Packets for unknown VLANs are not visible at all. Without hardware stripping, all VLAN packets are visible on the underlying device.
3) With hardware filtering, some drivers disable filtering in promiscous mode, some don't. The consensus of some discussions on netdev about this was that promiscous mode should disable all hardware filters, but keep HW acceleration enabled.
These patches fix point 1) and 2). Point 3) needs changes to the drivers and will be fixed separetly.
The first patch moves the VLAN tag from the cb to a new skb member, which is necessary to avoid clashes between VLANs and qdiscs/packet sockets use of the cb. This means on TX, packet sockets can get the tag from the skb.
The second patch uses the new skb field to store the VLAN TCI of stripped VLAN packets on RX and deliver them to packet sockets.
The third patch adds the VLAN TCI to the packet auxdata and delivers it to userspace, where it can be used to reconstruct the original packet.
The fourth patch modifies libpcap to reconstruct the original packet. There might be a better way to do this, but it was useful for testing.
There are mainly two remaining problems with this approach:
- socket filters for VLAN headers don't work properly since they expect the VLAN header to be present. Since with the approach taken by these patches, userspace has to have knowledge about VLAN acceleration anyway, it seems OK to simply add a filter instruction to filter on skb->vlan_tci and have userspace construct its filters accordingly.
- packet socket auxdata is only available for non-mmaped sockets. For mmaped sockets the only place to store the data is in struct tpacket_hdr, but that would break compatibility. Not sure what to do about this case.
Comments welcome.