On (12/30/16 16:33), Willem de Bruijn wrote: > > Once we define the interface as equivalent to v2, we cannot redefine it to > support v3-only features later.
What v3 only features do we think we want to support? Tpacket_v3 went in commit f6fb8f100b807378fda19e83e5ac6828b638603a : Date: Fri Aug 19 10:18:16 2011 +0000 since then apps that want to use the Rx benefits have to deal with this dual socket feature, where with "one socket for super-fast rx, zero Tx". The zero-tx part sounds like a regression to me. If we want to have something that does block Tx, and we cannot figure out how to retro-fit it to the exisiting APIs, we can always go for TPACKET_V4. > > TPACKET_V2 --> TPACKET_V3: > > - - Flexible buffer implementation: > > + - Flexible buffer implementation for RX_RING: > > 1. Blocks can be configured with non-static frame-size > > This is one of the main advantages of the v3 interface, and also sure, and we see some marginal benefits for this, when we try to use it for our apps. But the "marginal" part is not worth it, if I have to use separate sockets for tx and rx. > relevant to Tx. The current implementation does not consult > tpacket3_hdr->tp_next_offset and would preclude adding that > later. When is "later"? its been 6+ years. --Sowmini
