public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: passt-dev@passt.top, Laurent Vivier <lvivier@redhat.com>
Subject: Re: [PATCH 3/7] tcp_conn: Avoid 7-bit hole in struct tcp_splice_conn
Date: Thu, 30 Jan 2025 11:44:19 +1100	[thread overview]
Message-ID: <Z5rLY9Mu-9MSCNww@zatzit> (raw)
In-Reply-To: <20250129083340.38926745@elisabeth>

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

On Wed, Jan 29, 2025 at 08:33:40AM +0100, Stefano Brivio wrote:
> On Wed, 29 Jan 2025 12:02:09 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Tue, Jan 28, 2025 at 07:48:33AM +0100, Stefano Brivio wrote:
> > > On Tue, 28 Jan 2025 11:53:09 +1100
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >   
> > > > On Tue, Jan 28, 2025 at 12:15:28AM +0100, Stefano Brivio wrote:  
> > > > > Moving in_epoll out of the common flow data created a 7-bit hole in
> > > > > struct tcp_splice_conn: repack by shrinking @flags by one (otherwise
> > > > > unused) bit.    
> > > > 
> > > > Is this actually necessary for the migration stuff?  Or just a cleanup
> > > > you spotted along the way?  
> > > 
> > > I thought it was helpful to keep the same size on 32-bit, but it looks
> > > like it's not actually needed.
> > > 
> > > Let me drop it from this series as it's just noise and I'm trying to
> > > keep this slim. If we are all happy with it I can apply it. If not I'll
> > > forget about it.  
> > 
> > Eh, I don't care that much either way.
> > 
> > Note, btw, that bit-field packing is another way source and
> > destination could potentially have mismatching data structures.  IIUC
> > bit field packing is described by the ABI and doesn't necessarily
> > match the byte endianness.
> 
> Right, that's actually the reason that brought me to this change: I was
> comparing stuff between x86_64 and armv6l. On the other hand, this part
> of the specific ABI is generally considered stable so I can rely on it.

Uhh.. a specific ABI is stable, yes, but IIUC the whole point of these
endian, word size etc. checks is that you're not counting on it being
an identical ABI at each end.  I'm saying the bit field packing is
another way the ABIs at each end could differ, which is not currently
accounted for.

-- 
David Gibson (he or they)	| 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 --]

  reply	other threads:[~2025-01-30  0:53 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-27 23:15 [PATCH 0/7] Draft, incomplete series introducing state migration Stefano Brivio
2025-01-27 23:15 ` [PATCH 1/7] icmp, udp: Pad time_t timestamp to 64-bit to ease " Stefano Brivio
2025-01-28  0:49   ` David Gibson
2025-01-28  6:48     ` Stefano Brivio
2025-01-27 23:15 ` [PATCH 2/7] flow, flow_table: Pad flow table entries to 128 bytes, hash entries to 32 bits Stefano Brivio
2025-01-28  0:50   ` David Gibson
2025-01-27 23:15 ` [PATCH 3/7] tcp_conn: Avoid 7-bit hole in struct tcp_splice_conn Stefano Brivio
2025-01-28  0:53   ` David Gibson
2025-01-28  6:48     ` Stefano Brivio
2025-01-29  1:02       ` David Gibson
2025-01-29  7:33         ` Stefano Brivio
2025-01-30  0:44           ` David Gibson [this message]
2025-01-30  4:55             ` Stefano Brivio
2025-01-30  7:27               ` David Gibson
2025-01-27 23:15 ` [PATCH 4/7] flow_table: Use size in extern declaration for flowtab Stefano Brivio
2025-01-27 23:15 ` [PATCH 5/7] util: Add read_remainder() and read_all_buf() Stefano Brivio
2025-01-28  0:59   ` David Gibson
2025-01-28  6:48     ` Stefano Brivio
2025-01-29  1:03       ` David Gibson
2025-01-29  7:33         ` Stefano Brivio
2025-01-30  0:44           ` David Gibson
2025-01-27 23:15 ` [PATCH 6/7] Introduce facilities for guest migration on top of vhost-user infrastructure Stefano Brivio
2025-01-28  1:40   ` David Gibson
2025-01-28  6:50     ` Stefano Brivio
2025-01-29  1:16       ` David Gibson
2025-01-29  7:33         ` Stefano Brivio
2025-01-30  0:48           ` David Gibson
2025-01-30  4:55             ` Stefano Brivio
2025-01-30  7:38               ` David Gibson
2025-01-30  8:32                 ` Stefano Brivio
2025-01-30  8:54                   ` David Gibson
2025-01-27 23:15 ` [PATCH 7/7] Introduce passt-repair Stefano Brivio
2025-01-27 23:31   ` Stefano Brivio
2025-01-28  1:51   ` David Gibson
2025-01-28  6:51     ` Stefano Brivio
2025-01-29  1:29       ` David Gibson
2025-01-29  7:04         ` Stefano Brivio
2025-01-30  0:53           ` David Gibson
2025-01-30  4:55             ` Stefano Brivio
2025-01-30  7:43               ` David Gibson
2025-01-30  7:56                 ` 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=Z5rLY9Mu-9MSCNww@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).