[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1f45be856eae43a5bca0af524f5b02b9@AcuMS.aculab.com>
Date: Fri, 6 May 2022 08:09:44 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Maxim Mikityanskiy' <maximmi@...dia.com>
CC: Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Daniel Borkmann <daniel@...earbox.net>,
Paolo Abeni <pabeni@...hat.com>,
Boris Pismenny <borisp@...dia.com>,
Tariq Toukan <tariqt@...dia.com>,
"Saeed Mahameed" <saeedm@...dia.com>,
Gal Pressman <gal@...dia.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next] tls: Add opt-in zerocopy mode of sendfile()
From: Maxim Mikityanskiy
> Sent: 05 May 2022 19:28
>
> On 2022-05-05 16:48, David Laight wrote:
> > From: Maxim Mikityanskiy
> >> Sent: 05 May 2022 13:40
> >>
> >> On 2022-05-04 12:49, David Laight wrote:
> >>>>> If you declare the union on the stack in the callers, and pass by value
> >>>>> - is the compiler not going to be clever enough to still DDRT?
> >>>>
> >>>> Ah, OK, it should do the thing. I thought you wanted me to ditch the
> >>>> union altogether.
> >>>
> >>> Some architectures always pass struct/union by address.
> >>> Which is probably not what you had in mind.
> >>
> >> Do you have any specific architecture in mind? I couldn't find any
> >> information that it happens anywhere, x86_64 ABI [1] (pages 20-21)
> >> aligns with my expectations, and my common sense can't explain why would
> >> some architectures do what you say.
> >>
> >> In C, when the caller passes a struct as a parameter, the callee can
> >> freely modify it. If the compiler silently replaced it with a pointer,
> >> the callee would corrupt the caller's local variable, so such approach
> >> requires the caller to make an extra copy.
> >
> > Yes, that is what happens.
>
> I did a quick experiment with gcc 9 on m68k and i386, and it doesn't
> confirm what you claim.
>
> #include <stdint.h>
> #include <stdio.h>
>
> union test {
> uint32_t x;
> uint32_t *y;
> };
>
> void func1(void *ptr, union test t)
> {
> if (ptr) {
> printf("%p %u\n", ptr, t.x);
> } else {
> printf("%u\n", *t.y);
> }
> }
>
> void func2(void *ptr, uint32_t *y)
> {
> if (ptr) {
> printf("%p %u\n", ptr, (uint32_t)y);
> } else {
> printf("%u\n", *y);
> }
> }
>
> gcc -S test.c -fno-strict-aliasing -o -
>
> I believe this minimal example reflects well enough what happens in my
> code. The assembly generated for func1 and func2 are identical. In both
> cases the second parameter is passed on the stack by value, not by pointer.
Hmmm, perhaps it is/was only sparc32 that passed all structures by reference.
godbolt doesn't seem to have a sparc compiler and I don't have a
working sparc system any more.
It is also possible that the calling conventions are slightly
different than the ones I remember using years ago.
Certainly on i386 even 4 byte structures are returned by reference.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists