public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>
Cc: passt-dev@passt.top
Subject: Re: [RFC] tcp: Replace TCP buffer structure by an iovec array
Date: Wed, 13 Mar 2024 17:58:55 +0100	[thread overview]
Message-ID: <20240313175855.79826aa8@elisabeth> (raw)
In-Reply-To: <96b64a53-ad12-4fb3-9ff6-225e82df7c09@redhat.com>

On Wed, 13 Mar 2024 16:20:12 +0100
Laurent Vivier <lvivier@redhat.com> wrote:

> On 3/13/24 12:37, Stefano Brivio wrote:
> > On Mon, 11 Mar 2024 14:33:56 +0100
> > Laurent Vivier <lvivier@redhat.com> wrote:
> >   
> ...
> >> @@ -445,133 +413,78 @@ struct tcp_buf_seq_update {
> >>   };
> >>   
> >>   /* Static buffers */
> >> -
> >>   /**
> >> - * tcp4_l2_buf_t - Pre-cooked IPv4 packet buffers for tap connections
> >> - * @pad:	Align TCP header to 32 bytes, for AVX2 checksum calculation only
> >> - * @taph:	Tap-level headers (partially pre-filled)
> >> - * @iph:	Pre-filled IP header (except for tot_len and saddr)
> >> - * @uh:		Headroom for TCP header
> >> - * @data:	Storage for TCP payload
> >> + * tcp_l2_flags_t - TCP header and data to send option flags  
> > 
> > 'struct tcp_l2_flags_t - ...', by the way (pre-existing, I see).
> >   
> >> + * @th:		TCP header
> >> + * @opts	TCP option flags
> >>    */
> >> -static struct tcp4_l2_buf_t {
> >> -#ifdef __AVX2__
> >> -	uint8_t pad[26];	/* 0, align th to 32 bytes */
> >> -#else
> >> -	uint8_t pad[2];		/*	align iph to 4 bytes	0 */
> >> -#endif
> >> -	struct tap_hdr taph;	/* 26				2 */
> >> -	struct iphdr iph;	/* 44				20 */
> >> -	struct tcphdr th;	/* 64				40 */
> >> -	uint8_t data[MSS4];	/* 84				60 */
> >> -				/* 65536			65532 */
> >> +struct tcp_l2_flags_t {
> >> +	struct tcphdr th;
> >> +	char opts[OPT_MSS_LEN + OPT_WS_LEN + 1];
> >> +};  
> > 
> > This should still be aligned (when declared below) with:
> > 
> > #ifdef __AVX2__
> > } __attribute__ ((packed, aligned(32)))
> > #else
> > } __attribute__ ((packed, aligned(__alignof__(unsigned int))))
> > #endif
> > 
> > because yes, now you get the unsigned int alignment for free, but the
> > 32-byte boundary for AVX2 (checksums) not really, so that needs to be
> > there, and then for clarity I would keep the explicit attribute for the
> > non-AVX2 case.
> > 
> > By the way, I guess you could still combine the definition and
> > declaration as it was done earlier.  
> 
> We can't combine the definition and declaration because the same definition is used with 
> IPv4 and IPv6 TCP arrays declaration.

Ah, sorry, of course!

By the way of that, I wonder: would it then be possible to have a
single copy of payload buffers, that's shared for IPv4 and IPv6? We
would probably need to introduce a separate counter, on top of
tcp[46]_l2_buf_used (which could become tcp[46]_l2_hdr_used).

Well, probably not in scope for this change anyway.

> I'm not sure: the __attribute__ must be used on the structure definition or on the array 
> of structures declaration?

__attribute__ can be used on definitions or declarations depending on
the type of attribute itself -- here it would be on the definition,
because it affects the definition of the data type itself.

Strictly speaking, you can use it on the declaration too, but gcc will
ignore it:

$ cat attr.c
struct a {
    int b;
};

int main()
{
    struct a c __attribute__ ((packed, aligned(32)));
    return 0;
}

$ gcc -o attr attr.c
attr.c: In function ‘main’:
attr.c:7:12: warning: ‘packed’ attribute ignored [-Wattributes]
    7 |     struct a c __attribute__ ((packed, aligned(32)));
      |            

-- 
Stefano


  reply	other threads:[~2024-03-13 16:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-11 13:33 [RFC] tcp: Replace TCP buffer structure by an iovec array Laurent Vivier
2024-03-12 22:56 ` Stefano Brivio
2024-03-13 11:37 ` Stefano Brivio
2024-03-13 14:42   ` Laurent Vivier
2024-03-13 15:27     ` Stefano Brivio
2024-03-13 15:20   ` Laurent Vivier
2024-03-13 16:58     ` Stefano Brivio [this message]
2024-03-14 14:07   ` Laurent Vivier
2024-03-14 15:47     ` Stefano Brivio
2024-03-14 15:54       ` Laurent Vivier
2024-03-14 16:26         ` Stefano Brivio
2024-03-15  0:46           ` David Gibson
2024-03-14  4:22 ` David Gibson

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=20240313175855.79826aa8@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=passt-dev@passt.top \
    /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).