netdev - Re: [PATCH net-next 1/6] xdp: introduce mb in xdp_buff/xdp

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200824104442.023bdd11@carbon>
Date:   Mon, 24 Aug 2020 10:44:42 +0200
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Shay Agroskin <shayagr@...zon.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>, brouer@...hat.com
Subject: Re: [PATCH net-next 1/6] xdp: introduce mb in xdp_buff/xdp_frame

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.

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer