>> 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?
Variable length slots seems like the only one from that list that makes sense on Tx. It is already possible to prepare multiple buffers before triggering transmit, so the block-based signal moderation is not very relevant. > 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. What is the issue with using separate sockets that you are having? I generally end up using that even with V2. > 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. But the semantics for V3 are currenty well defined. Calling something V3, but using V2 semantics is a somewhat unintuitive interface to me. I don't see a benefit in defining something that does not implement any new features. Especially if it blocks adding the expected semantics later. That said, if there is a workload that benefits from using a single socket, and especially if it can be forward compatible with support for variable sized slots, then I do not object. I was just having a look at that second point, actually. Could you also extend the TX_RING test in tools/testing/selftests/net/psock_tpacket.c if there are no other blocking issues?
