lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 26 Aug 2020 12:47:42 +0300
From:   Shay Agroskin <shayagr@...zon.com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
CC:     Lorenzo Bianconi <lorenzo@...nel.org>, <netdev@...r.kernel.org>,
        <bpf@...r.kernel.org>, <davem@...emloft.net>,
        <lorenzo.bianconi@...hat.com>, <echaudro@...hat.com>,
        <sameehj@...zon.com>, <kuba@...nel.org>
Subject: Re: [PATCH net-next 1/6] xdp: introduce mb in xdp_buff/xdp_frame


Jesper Dangaard Brouer <brouer@...hat.com> writes:

> On Sun, 23 Aug 2020 17:08:30 +0300
> Shay Agroskin <shayagr@...zon.com> wrote:
>
>> > diff --git a/include/net/xdp.h b/include/net/xdp.h
>> > index 3814fb631d52..42f439f9fcda 100644
>> > --- a/include/net/xdp.h
>> > +++ b/include/net/xdp.h
>> > @@ -72,7 +72,8 @@ struct xdp_buff {
>> >  	void *data_hard_start;
>> >  	struct xdp_rxq_info *rxq;
>> >  	struct xdp_txq_info *txq;
>> > -	u32 frame_sz; /* frame size to deduce 
>> > data_hard_end/reserved tailroom*/
>> > +	u32 frame_sz:31; /* frame size to deduce 
>> > data_hard_end/reserved tailroom*/
>> > +	u32 mb:1; /* xdp non-linear buffer */
>> >  };
>> >  
>> >  /* Reserve memory area at end-of data area.
>> > @@ -96,7 +97,8 @@ struct xdp_frame {
>> >  	u16 len;
>> >  	u16 headroom;
>> >  	u32 metasize:8;
>> > -	u32 frame_sz:24;
>> > +	u32 frame_sz:23;
>> > +	u32 mb:1; /* xdp non-linear frame */  
>> 
>> Although this issue wasn't introduced with this patch, why not 
>> make frame_sz field to be the same size in xdp_buff and 
>> xdp_frame 
>> ?
>
> This is all about struct layout and saving memory size, due to
> cacheline access. Please read up on this and use the tool pahole 
> to
> inspect the struct memory layout.

I actually meant reducing the size of frame_sz in xdp_buff 
(without changing xdp_frame so that it still fits 64 byte cache 
line). Reducing a field size shouldn't affect cache alignment as 
far as I can see.
Doesn't matter all that much to me, I simply find it a better 
practice that the same field would have same size in different 
structs.

Shay

Powered by blists - more mailing lists