Re: [PATCH 0/4] Some improvements to the tap send path

[Laurent Vivier <lvivier@redhat.com>]

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

Thanks,
Laurent