On Fri, Mar 08, 2024 at 09:18:48AM +0100, Laurent Vivier wrote:
> On 3/8/24 07:53, David Gibson wrote:
> > This series has a handful of small improvements to the tap send path.
> > See individual commit messages for the details.
> > 
> > I expect this will conflict with Laurent's upcoming work.  I hope the
> > conflicts won't be too bad, and indeed will set us up for less
> > duplication there in the end.
> 
> I'm working on patch that devides TCP buffers in several buffers pointed out
> by an IOV arrays and then provided to tap_send_frames(). I'm going to base
> my patch on this series.
> 
> The idea is:
> 
> A frame is made with 4 iovecs:
> 
> #define TCP_IOV_VNET    0
> #define TCP_IOV_ETH     1
> #define TCP_IOV_IP      2
> #define TCP_IOV_PAYLOAD 3
> #define TCP_IOV_NUM     4
> typedef struct iovec tap_iovec_t[TCP_IOV_NUM];

General concept seems good.  Unless you have a specific reason to do
so, I'd suggest keeping VNET and ETH - i.e. L2 and everything below it
- together.  As well as just making one less buffer for each frame, I
think that will make life easier if we want to add an L2 interface
with non-Ethernet framing (e.g. "tun" instead of "tap").

> 
> The payload can be TCP + data or TCP + flags:
> 
> struct tcp_l2_flags_t {
>         struct tcphdr th;
>         char opts[OPT_MSS_LEN + OPT_WS_LEN + 1];
> };
> 
> struct tcp_l2_payload_t {
>         struct tcphdr th;       /*    20 bytes */
>         uint8_t data[MSS];      /* 65516 bytes */
> #ifdef __AVX2__
> } __attribute__ ((packed, aligned(32)));
> #else
> } __attribute__ ((packed, aligned(__alignof__(unsigned int))));
> #endif

Not sure if we'd be better off with this approach, or having both IP
and L4 headers together, and the L4 payload in another.  The latter
would mean duplicating the TCP or UDP headers between the IPv4 and
IPv6 cases, but it allows the data buffers - which will be used
directly on the socket side.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson