On Mon, Mar 11, 2024 at 12:02:08PM +0100, Laurent Vivier wrote:
> On 3/8/24 13:42, David Gibson wrote:
> > 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").
> > 
> 
> In fact keeping vnet header separated from eth header makes easier to remove
> it from the list to pass the iovec array to pcap functions and to pasta send
> function (can use iovec[1] and iovcount - 1).

Ok, fair point.

-- 
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