public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Laurent Vivier <lvivier@redhat.com>
Cc: Stefano Brivio <sbrivio@redhat.com>, passt-dev@passt.top
Subject: Re: [PATCH 0/4] Some improvements to the tap send path
Date: Fri, 8 Mar 2024 23:42:28 +1100	[thread overview]
Message-ID: <ZesHtLGzv5TRJnzb@zatzit> (raw)
In-Reply-To: <348a52c9-7c07-4150-b594-4743c7775be6@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2024-03-08 12:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-08  6:53 [PATCH 0/4] Some improvements to the tap send path David Gibson
2024-03-08  6:53 ` [PATCH 1/4] tap: Extend tap_send_frames() to allow multi-buffer frames David Gibson
2024-03-14  7:02   ` Stefano Brivio
2024-03-14  8:47     ` David Gibson
2024-03-08  6:53 ` [PATCH 2/4] tap: Simplify some casts in the tap "slow path" functions David Gibson
2024-03-08  6:53 ` [PATCH 3/4] tap: Implement tap_send() "slow path" in terms of fast path David Gibson
2024-03-08  6:53 ` [PATCH 4/4] tap: Rename tap_iov_{base,len} David Gibson
2024-03-08  8:18 ` [PATCH 0/4] Some improvements to the tap send path Laurent Vivier
2024-03-08  8:34   ` Stefano Brivio
2024-03-08  8:55     ` Laurent Vivier
2024-03-08 15:49     ` Laurent Vivier
2024-03-08 16:24       ` Stefano Brivio
2024-03-08 12:42   ` David Gibson [this message]
2024-03-08 16:49     ` Laurent Vivier
2024-03-09  4:15       ` David Gibson
2024-03-11 11:02     ` Laurent Vivier
2024-03-14  2:22       ` David Gibson
2024-03-14 16:40 ` Stefano Brivio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZesHtLGzv5TRJnzb@zatzit \
    --to=david@gibson.dropbear.id.au \
    --cc=lvivier@redhat.com \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).