From: Lorenzo Bianconi <lorenzo@kernel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
Daniel Borkmann <daniel@iogearbox.net>,
bpf@vger.kernel.org, netdev@vger.kernel.org, davem@davemloft.net,
kuba@kernel.org, ast@kernel.org, brouer@redhat.com,
alexander.duyck@gmail.com, saeed@kernel.org
Subject: Re: [PATCH v3 bpf-next 2/2] net: xdp: introduce xdp_prepare_buff utility routine
Date: Tue, 15 Dec 2020 21:36:46 +0100 [thread overview]
Message-ID: <20201215203646.GA910956@lore-desk> (raw)
In-Reply-To: <20201215151344.GA24650@ranger.igk.intel.com>
[-- Attachment #1: Type: text/plain, Size: 4204 bytes --]
> On Tue, Dec 15, 2020 at 04:06:20PM +0100, Lorenzo Bianconi wrote:
> > > On 12/15/20 2:47 PM, Lorenzo Bianconi wrote:
> > > [...]
> > > > > > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > > > > > index 329397c60d84..61d3f5f8b7f3 100644
> > > > > > --- a/drivers/net/xen-netfront.c
> > > > > > +++ b/drivers/net/xen-netfront.c
> > > > > > @@ -866,10 +866,8 @@ static u32 xennet_run_xdp(struct netfront_queue *queue, struct page *pdata,
> > > > > > xdp_init_buff(xdp, XEN_PAGE_SIZE - XDP_PACKET_HEADROOM,
> > > > > > &queue->xdp_rxq);
> > > > > > - xdp->data_hard_start = page_address(pdata);
> > > > > > - xdp->data = xdp->data_hard_start + XDP_PACKET_HEADROOM;
> > > > > > + xdp_prepare_buff(xdp, page_address(pdata), XDP_PACKET_HEADROOM, len);
> > > > > > xdp_set_data_meta_invalid(xdp);
> > > > > > - xdp->data_end = xdp->data + len;
> > > > > > act = bpf_prog_run_xdp(prog, xdp);
> > > > > > switch (act) {
> > > > > > diff --git a/include/net/xdp.h b/include/net/xdp.h
> > > > > > index 3fb3a9aa1b71..66d8a4b317a3 100644
> > > > > > --- a/include/net/xdp.h
> > > > > > +++ b/include/net/xdp.h
> > > > > > @@ -83,6 +83,18 @@ xdp_init_buff(struct xdp_buff *xdp, u32 frame_sz, struct xdp_rxq_info *rxq)
> > > > > > xdp->rxq = rxq;
> > > > > > }
> > > > > > +static inline void
> > >
> > > nit: maybe __always_inline
> >
> > ack, I will add in v4
> >
> > >
> > > > > > +xdp_prepare_buff(struct xdp_buff *xdp, unsigned char *hard_start,
> > > > > > + int headroom, int data_len)
> > > > > > +{
> > > > > > + unsigned char *data = hard_start + headroom;
> > > > > > +
> > > > > > + xdp->data_hard_start = hard_start;
> > > > > > + xdp->data = data;
> > > > > > + xdp->data_end = data + data_len;
> > > > > > + xdp->data_meta = data;
> > > > > > +}
> > > > > > +
> > > > > > /* Reserve memory area at end-of data area.
> > > > > > *
> > >
> > > For the drivers with xdp_set_data_meta_invalid(), we're basically setting xdp->data_meta
> > > twice unless compiler is smart enough to optimize the first one away (did you double check?).
> > > Given this is supposed to be a cleanup, why not integrate this logic as well so the
> > > xdp_set_data_meta_invalid() doesn't get extra treatment?
>
> That's what I was trying to say previously.
>
> >
> > we discussed it before, but I am fine to add it in v4. Something like:
> >
> > static __always_inline void
> > xdp_prepare_buff(struct xdp_buff *xdp, unsigned char *hard_start,
> > int headroom, int data_len, bool meta_valid)
> > {
> > unsigned char *data = hard_start + headroom;
> >
> > xdp->data_hard_start = hard_start;
> > xdp->data = data;
> > xdp->data_end = data + data_len;
> > xdp->data_meta = meta_valid ? data : data + 1;
>
> This will introduce branch, so for intel drivers we're getting the
> overhead of one add and a branch. I'm still opting for a separate helper.
>
> static __always_inline void
> xdp_prepare_buff(struct xdp_buff *xdp, unsigned char *hard_start,
> int headroom, int data_len)
> {
> unsigned char *data = hard_start + headroom;
>
> xdp->data_hard_start = hard_start;
> xdp->data = data;
> xdp->data_end = data + data_len;
> xdp_set_data_meta_invalid(xdp);
> }
>
> static __always_inline void
> xdp_prepare_buff_meta(struct xdp_buff *xdp, unsigned char *hard_start,
> int headroom, int data_len)
> {
> unsigned char *data = hard_start + headroom;
>
> xdp->data_hard_start = hard_start;
> xdp->data = data;
> xdp->data_end = data + data_len;
> xdp->data_meta = data;
> }
yes, to follow-up the possible approaches we have here are:
- have 2 different helpers (xdp_prepare_buff_meta and xdp_prepare_buff) as
suggested by Maciej
- move the data_meta initialization out of the helper and do it in each
driver
- use the current approach and overwrite data_meta with
xdp_set_data_meta_invalid() when necessary
- introduce a branch in order to have just one helper
what is the best for you?
Regards,
Lorenzo
>
> > }
> >
> > Regards,
> > Lorenzo
> >
> > >
> > > Thanks,
> > > Daniel
> > >
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2020-12-15 20:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-12 17:41 [PATCH v3 bpf-next 0/2] introduce xdp_init_buff/xdp_prepare_buff Lorenzo Bianconi
2020-12-12 17:41 ` [PATCH v3 bpf-next 1/2] net: xdp: introduce xdp_init_buff utility routine Lorenzo Bianconi
2020-12-16 8:35 ` Jesper Dangaard Brouer
2020-12-16 14:56 ` Lorenzo Bianconi
2020-12-12 17:41 ` [PATCH v3 bpf-next 2/2] net: xdp: introduce xdp_prepare_buff " Lorenzo Bianconi
2020-12-15 12:36 ` Maciej Fijalkowski
2020-12-15 13:47 ` Lorenzo Bianconi
2020-12-15 14:51 ` Daniel Borkmann
2020-12-15 15:06 ` Lorenzo Bianconi
2020-12-15 15:13 ` Maciej Fijalkowski
2020-12-15 20:36 ` Lorenzo Bianconi [this message]
2020-12-16 8:30 ` Jesper Dangaard Brouer
2020-12-16 8:52 ` Jesper Dangaard Brouer
2020-12-16 15:01 ` Lorenzo Bianconi
2020-12-17 18:16 ` Saeed Mahameed
2020-12-17 18:28 ` Maciej Fijalkowski
2020-12-17 20:31 ` Saeed Mahameed
2020-12-14 15:32 ` [PATCH v3 bpf-next 0/2] introduce xdp_init_buff/xdp_prepare_buff Martin Habets
2020-12-14 17:53 ` Camelia Alexandra Groza
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=20201215203646.GA910956@lore-desk \
--to=lorenzo@kernel.org \
--cc=alexander.duyck@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=lorenzo.bianconi@redhat.com \
--cc=maciej.fijalkowski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=saeed@kernel.org \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.