DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Loftus, Ciara" <ciara.loftus@intel.com>
To: "Yigit, Ferruh" <ferruh.yigit@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH RFC 1/1] net/af_xdp: shared UMEM support
Date: Wed, 26 Aug 2020 08:37:16 +0000	[thread overview]
Message-ID: <3cbf307e8b8a4e0392bba4e3c6c59165@intel.com> (raw)
In-Reply-To: <d45d5ec1-992a-7cbf-2129-35761013f8e9@intel.com>


> 
> On 8/11/2020 10:50 AM, Ciara Loftus wrote:
> > A future kernel will introduce the ability to efficiently share a UMEM
> > between AF_XDP sockets bound to different queue ids on the same or
> > different devices. This patch integrates that functionality into the AF_XDP
> > PMD.
> >
> > A PMD will attempt to share a UMEM with others if the shared_umem=1
> vdev
> > arg is set. UMEMs can only be shared across PMDs with the same
> mempool, up
> > to a limited number of PMDs goverened by the size of the given mempool.
> >
> > The benefit of sharing UMEM across PMDs is a saving in memory due to not
> > having to register the UMEM multiple times.
> >
> > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> 
> <...>
> 
> > @@ -1,5 +1,5 @@
> >  /* SPDX-License-Identifier: BSD-3-Clause
> > - * Copyright(c) 2019 Intel Corporation.
> > + * Copyright(c) 2020 Intel Corporation.
> >   */
> >  #include <unistd.h>
> >  #include <errno.h>
> > @@ -15,6 +15,7 @@
> >  #include <linux/if_link.h>
> >  #include <linux/ethtool.h>
> >  #include <linux/sockios.h>
> > +#include <linux/version.h>
> >  #include "af_xdp_deps.h"
> >  #include <bpf/xsk.h>
> >
> > @@ -37,6 +38,11 @@
> >  #include <rte_mbuf.h>
> >  #include <rte_malloc.h>
> >  #include <rte_ring.h>
> > +#include <rte_spinlock.h>
> > +
> > +#if KERNEL_VERSION(5, 7, 0) < LINUX_VERSION_CODE
> > +#define ETH_AF_XDP_SHARED_UMEM 1
> > +#endif
> 
> I think better to separate these version checks from the actual code, what do
> you think creating a compat.h under 'net/af_xdp' and move above logic
> there?

Good suggestion. Much cleaner. I'll implement this.

> 
> <...>
> 
> > @@ -888,9 +1048,15 @@ xsk_configure(struct pmd_internals *internals,
> struct pkt_rx_queue *rxq,
> >  	cfg.bind_flags |= XDP_USE_NEED_WAKEUP;
> >  #endif
> >
> > -	ret = xsk_socket__create(&rxq->xsk, internals->if_name,
> > -			rxq->xsk_queue_idx, rxq->umem->umem, &rxq->rx,
> > -			&txq->tx, &cfg);
> > +	if (!internals->shared_umem_configured) {
> > +		ret = xsk_socket__create(&rxq->xsk, internals->if_name,
> > +				rxq->xsk_queue_idx, rxq->umem->umem,
> &rxq->rx,
> > +				&txq->tx, &cfg);
> > +	} else {
> > +		ret = xsk_socket__create_shared(&rxq->xsk, internals-
> >if_name,
> > +				rxq->xsk_queue_idx, rxq->umem->umem,
> &rxq->rx,
> > +				&txq->tx, &rxq->fq, &rxq->cq, &cfg);
> > +	}
> 
> Is the above dependency (ETH_AF_XDP_SHARED_UMEM) for the kernel
> 'af_xdp' code,
> or for 'libbpf.so'?
> 
> The 'xsk_socket__create_shared()' API is not available in the latest
> 'libbpf.so', I wonder if the kernel version check is to align with the correct
> 'libbpf.so' version.
> If not how the dependent version of the 'libbpf.so' managed for DPDK?

Good point.
For the RFC I'm assuming the user is using libbpf packaged with the kernel both with appropriate support.
In the next RFC/v1 I'll introduce a check for both the correct libbpf version and underlying kernel support, as both are required.

Thanks,
Ciara


  reply	other threads:[~2020-08-26  8:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-11  9:50 [dpdk-dev] [PATCH RFC 0/1] " Ciara Loftus
2020-08-11  9:50 ` [dpdk-dev] [PATCH RFC 1/1] " Ciara Loftus
2020-08-25 14:09   ` Ferruh Yigit
2020-08-26  8:37     ` Loftus, Ciara [this message]
2020-08-25 12:14 ` [dpdk-dev] [PATCH RFC 0/1] " Ferruh Yigit
2020-08-26  7:45   ` Loftus, Ciara

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=3cbf307e8b8a4e0392bba4e3c6c59165@intel.com \
    --to=ciara.loftus@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.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.
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 NNTP newsgroup(s).