> Subject: [PATCH v4 3/6] net/intel: add TxPP Support for E830
>
> Add support for Tx Time based queues. This is used to schedule
> packets based on Tx timestamp.
>
> Signed-off-by: Soumyadeep Hore
> ---
> drivers/net/intel/common/tx.h | 14 ++
> drivers/net/intel/ice/base/ice_lan
> Subject: [PATCH v4 2/6] net/intel: add read clock feature in ICE
Since the change is specific to the ice driver only, I think the title should
change to "net/ice" and you can drop the mention of "in ICE" in the message
that follows the colon.
>
> Adding eth_ice_read_clock() feature to get cu
>
> When using only 3 scheduler levels, the VSI node needs to be a node
> further down the scheduler hierarchy, rather than one up it as with all
> other possible level settings (5-9). Take account of this possibility in
> the code.
>
> Fixes: 4ace7701eb44 ("net/ice: provide parameter to limit sc
Hi Vivek,
Could you please send me meson-logs/meson-log.txt? It will tell me what version
of libbpf you are using and some other useful info.
It looks to me that the af_xdp meson build is not correctly determining what
libbpf functions are available in your environment.
As a side note, if you d
> -Original Message-
> From: Du, Frank
> Sent: Thursday, May 23, 2024 8:56 AM
> To: Morten Brørup ; Ferruh Yigit
> ; dev@dpdk.org; Andrew Rybchenko
> ; Burakov, Anatoly
>
> Cc: Loftus, Ciara
> Subject: RE: [PATCH v2] net/af_xdp: fix umem map size for zer
> Subject: [PATCH v6 4/9] net/af_xdp: use generic SW stats
>
> Use common code for all SW stats.
>
> Signed-off-by: Stephen Hemminger
> ---
> drivers/net/af_xdp/rte_eth_af_xdp.c | 98 -
> 1 file changed, 25 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/net
>
> The current calculation assumes that the mbufs are contiguous. However,
> this assumption is incorrect when the memory spans across a huge page.
> Correct to directly read the size from the mempool memory chunks.
>
> Signed-off-by: Frank Du
Hi Frank,
Thanks for the patch.
Before your patc
>
> On Fri, 10 May 2024 10:03:57 +
> Ciara Loftus wrote:
>
> > diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
> b/drivers/net/af_xdp/rte_eth_af_xdp.c
> > index fee0d5d5f3..968bbf6d45 100644
> > --- a/drivers/net/af_xdp/rte_eth_af_xdp.c
> > +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
> > @@ -
> >
> > > Subject: [PATCH] net/af_xdp: fix umem map size for zero copy
> > >
> > > The current calculation assumes that the mbufs are contiguous.
> > > However, this assumption is incorrect when the memory spans across a
> huge
> > page.
> > > Correct to directly read the size from the mempool memo
> Subject: [PATCH] net/af_xdp: fix umem map size for zero copy
>
> The current calculation assumes that the mbufs are contiguous. However,
> this assumption is incorrect when the memory spans across a huge page.
> Correct to directly read the size from the mempool memory chunks.
>
> Signed-off-by
> Subject: [v1 1/1] docs: af_xdp device plugin repo update
>
> Fixup the references to the AF_XDP Device Plugin repo.
>
> Fixes: 66a2aca4f512 ("docs: fix AF_XDP device plugin howto")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Maryam Tahhan
Acked-by: Ciara Loftus
> ---
> doc/guides/howto/af_xd
> Subject: [v1 1/1] MAINTAINERS: add another AF_XDP maintainer
>
> Add Maryam Tahhan as an additional maintainer for AF_XDP
> PMD and it's documentation.
>
> Signed-off-by: Maryam Tahhan
Thanks Maryam.
Acked-by: Ciara Loftus
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> d
>
> The original `use_cni` implementation was limited to
> supporting only a single netdev in a DPDK pod. This patchset
> aims to fix this limitation transparently to the end user.
> It will also enable compatibility with the latest AF_XDP
> Device Plugin.
>
> Signed-off-by: Maryam Tahhan
Thank
>
> +#ifdef ETH_AF_XDP_UPDATE_XSKMAP
> +static __rte_always_inline int
> +update_xskmap(struct xsk_socket *xsk, int map_fd, int xsk_queue_idx
> __rte_unused)
> +{
> + return xsk_socket__update_xskmap(xsk, map_fd);
> +}
> +#else
> +static __rte_always_inline int
> +update_xskmap(struct xsk_so
snip
> @@ -1695,17 +1699,16 @@ xsk_configure(struct pmd_internals *internals,
> struct pkt_rx_queue *rxq,
> }
>
> if (internals->use_cni) {
> - int err, fd, map_fd;
> + int err, map_fd;
>
> - /* get socket fd from CNI plugin */
> - map_
> Subject: [PATCH v2] net/af_xdp: fix resources leak when xsk configure fails
>
> In xdp_umem_configure() allocated some resources for the
> xsk umem, we should delete them when xsk configure fails,
> otherwise it will lead to resources leak.
>
> Fixes: f1debd77efaf ("net/af_xdp: introduce AF_XDP
> Subject: [v9 2/3] net/af_xdp: fix multi interface support for K8s
>
> The original 'use_cni' implementation, was added
> to enable support for the AF_XDP PMD in a K8s env
> without any escalated privileges.
> However 'use_cni' used a hardcoded socket rather
> than a configurable one. If a DPDK p
>
> On 22/02/2024 03:07, Yunjian Wang wrote:
> In xdp_umem_configure() allocated some resources for the
> xsk umem, we should delete them when xsk configure fails,
> otherwise it will lead to resources leak.
>
> Fixes: f1debd77efaf ("net/af_xdp: introduce AF_XDP PMD")
> Cc: mailto:sta...@dpdk.org
>
> On 1/11/2024 2:21 PM, Ferruh Yigit wrote:
> > On 1/11/2024 12:21 PM, Maryam Tahhan wrote:
> >> On 11/01/2024 11:35, Ferruh Yigit wrote:
> >>> Devarg is user interface, changing it impacts the user.
> >>>
> >>> Assume that user of '22.11.3' using 'use_cni' dev_arg, it will be broken
> >>> when
>
> With the original 'use_cni' implementation, (using a
> hardcoded socket rather than a configurable one),
> if a DPDK pod is requesting multiple net devices
> and these devices are from different pools, then
> the container attempts to mount all the netdev UDSes
> in the pod as /tmp/afxdp.sock.
Thanks for the latest patch Maryam. I have one minor suggestion inline.
Also, there are still some references to "use_cni" in af_xdp.rst which should
be removed/replaced with uds_path.
Once that's done I think the patch should be good to go. Perhaps also consider
adding a note to the release note
> -Original Message-
> From: Maryam Tahhan
> Sent: Monday, December 4, 2023 10:31 AM
> To: ferruh.yi...@amd.com; step...@networkplumber.org;
> lihuis...@huawei.com; fengcheng...@huawei.com;
> liuyongl...@huawei.com; Koikkara Reeny, Shibin
>
> Cc: dev@dpdk.org; Tahhan, Maryam
> Subject
>
> In xdp_umem_configure() allocated memzone for the 'umem', we should
> free it when xsk_umem__create() call fails, otherwise it will lead to
> memory zone leak. To fix it move 'umem->mz = mz;' assignment after
> 'mz == NULL' check.
>
> Fixes: f1debd77efaf ("net/af_xdp: introduce AF_XDP PMD")
>
> On 7/20/2023 8:45 AM, Ferruh Yigit wrote:
> > On 7/19/2023 5:12 PM, Stephen Hemminger wrote:
> >> On Wed, 19 Jul 2023 11:03:36 +0100
> >> Ferruh Yigit wrote:
> >>
> >>> On 7/19/2023 11:00 AM, Ferruh Yigit wrote:
> On 7/17/2023 8:15 PM, Stephen Hemminger wrote:
> > The tap_bpf_program.c
>
> >
> > On 6/24/22 13:23, Ciara Loftus wrote:
> > > libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and
> > >> bpf_set_link_xdp_fd
> > > functions. Use meson to detect if libbpf >= v0.7.0 is linked and if
> > > so,
> > use
> > > the recommended replacement functions b
>
> On 6/24/22 13:23, Ciara Loftus wrote:
> > libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and
> >> bpf_set_link_xdp_fd
> > functions. Use meson to detect if libbpf >= v0.7.0 is linked and if so,
> use
> > the recommended replacement functions bpf_xdp_query_id,
> bpf_
>
> On 6/27/22 17:17, Loftus, Ciara wrote:
> >>
> >> On 6/24/22 13:23, Ciara Loftus wrote:
> >>> libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and
> bpf_set_link_xdp_fd
> >>> functions. Use meson to detect if libbpf >= v0.7.0 is linked a
>
> On 6/24/22 13:23, Ciara Loftus wrote:
> > libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and bpf_set_link_xdp_fd
> > functions. Use meson to detect if libbpf >= v0.7.0 is linked and if so, use
> > the recommended replacement functions bpf_xdp_query_id,
> bpf_xdp_attach
> > and bpf_xdp_detach
>
> 24/06/2022 08:06, Ciara Loftus:
> > Linking with libbpf v0.8.0 causes deprication warnings. As a temporary
> > measure, prevent linking with libbpf versions v0.8.0 and greater. This
> > limitation should be removed in the future when appropriate
> > compatibility measures are introduced.
> >
>
>
> 24/06/2022 00:18, Ferruh Yigit:
> > On 6/23/2022 10:58 PM, Thomas Monjalon wrote:
> > > Hi,
> > >
> > > It seems DPDK is not compatible with libbpf 0.8:
> > >
> > > drivers/net/af_xdp/rte_eth_af_xdp.c:871:6: error: 'bpf_get_link_xdp_id'
> is deprecated: libbpf v0.8+: use bpf_xdp_query_id() ins
>
> 10/03/2022 09:49, Loftus, Ciara:
> > > When the PMD is configured to load a custom XDP program, it sets
> > > XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD flag to prevent libbpf from
> > > loading its default XDP program. However, when queue_count is set to
> >
> When the PMD is configured to load a custom XDP program, it sets
> XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD flag to prevent libbpf from
> loading its default XDP program. However, when queue_count is set to
> greater than 1, this flag is only set for the first XSK socket but not
> for subsequent XSK s
> Subject: Re: [PATCH] net/af_xdp: make the PMD compatible with libbpf >=
> v0.7.0
>
> On Thu, Feb 17, 2022 at 12:14:30PM +, Ciara Loftus wrote:
> > libbpf v0.7.0 deprecates the bpf_prog_load function. Use meson to detect
> > if libbpf >= v0.7.0 is linked and if so, use the recommended replace
> Subject: [PATCH] net/af_xdp: add missing trailing newline in logs
>
> Caught while trying --in-memory mode, some log messages in this driver
> are not terminated with a newline:
> rte_pmd_af_xdp_probe(): net_af_xdp: Failed to register multi-process IPC
> callback: Operation not supportedvdev_pro
> Subject: [PATCH v2] net/af_xdp: allow operation when multiprocess is
> disabled
>
> If EAL multiprocess feature has been disabled via rte_mp_disable()
> function, AF_XDP driver may not be able to register its IPC callback.
> Previously this leads to probe failure.
> This commit adds a check for
> Subject: RE: [PATCH v4] net/af_xdp: re-enable secondary process support
>
> >
> > On 2/11/2022 1:01 PM, Loftus, Ciara wrote:
> > >>
> > >> On 2/11/2022 9:26 AM, Loftus, Ciara wrote:
> > >>>>>
> > >>>>> On 2/10/2
>
> On 2/11/2022 1:01 PM, Loftus, Ciara wrote:
> >>
> >> On 2/11/2022 9:26 AM, Loftus, Ciara wrote:
> >>>>>
> >>>>> On 2/10/2022 5:47 PM, Loftus, Ciara wrote:
> >>>>>>> Subject: Re: [PATCH v4] net/af_xdp: re-enab
>
> On 2/11/2022 9:26 AM, Loftus, Ciara wrote:
> >>>
> >>> On 2/10/2022 5:47 PM, Loftus, Ciara wrote:
> >>>>> Subject: Re: [PATCH v4] net/af_xdp: re-enable secondary process
> >> support
> >>>>>
> >>>>>
> >
> > On 2/10/2022 5:47 PM, Loftus, Ciara wrote:
> > >> Subject: Re: [PATCH v4] net/af_xdp: re-enable secondary process
> support
> > >>
> > >> On 2/10/2022 3:40 PM, Loftus, Ciara wrote:
> > >>>> Subject: Re: [PATCH v4] net/af_
>
> On 2/10/2022 5:47 PM, Loftus, Ciara wrote:
> >> Subject: Re: [PATCH v4] net/af_xdp: re-enable secondary process support
> >>
> >> On 2/10/2022 3:40 PM, Loftus, Ciara wrote:
> >>>> Subject: Re: [PATCH v4] net/af_xdp: re-enable secondary pro
> Subject: Re: [PATCH v4] net/af_xdp: re-enable secondary process support
>
> On 2/10/2022 3:40 PM, Loftus, Ciara wrote:
> >> Subject: Re: [PATCH v4] net/af_xdp: re-enable secondary process support
> >>
> >> On 2/9/2022 9:48 AM, Ciara Loftus wrote:
>
> Subject: Re: [PATCH v4] net/af_xdp: re-enable secondary process support
>
> On 2/9/2022 9:48 AM, Ciara Loftus wrote:
> > Secondary process support had been disabled for the AF_XDP PMD
> because
> > there was no logic in place to share the AF_XDP socket file descriptors
> > between the processes.
> Subject: [PATCH v1] net/af_xdp: make umem configure code more readable
>
> The below compile time defined style make the code not so readable, the
> first function end block is after "#endif" segment.
>
> #if defined(XDP_UMEM_UNALIGNED_CHUNK_FLAG)
>
> xdp_umem_configure()
> {
> Subject: [PATCH] ethdev: introduce generic dummy packet burst function
>
> Multiple PMDs have dummy/noop Rx/Tx packet burst functions.
>
> These dummy functions are very simple, introduce a common function in
> the ethdev and update drivers to use it instead of each driver having
> its own func
>
> On 2/8/2022 6:42 PM, Stephen Hemminger wrote:
> > On Tue, 8 Feb 2022 18:00:27 +
> > Ferruh Yigit wrote:
> >
> >> On 2/8/2022 5:45 PM, Stephen Hemminger wrote:
> >>> On Tue, 8 Feb 2022 13:48:00 +
> >>> Ciara Loftus wrote:
> >>>
> +- **Secondary Processes**
> +
> + Rx
> >>
> >> On 2/4/2022 12:54 PM, Ciara Loftus wrote:
> >>> Secondary process support had been disabled for the AF_XDP PMD
> >>> because there was no logic in place to share the AF_XDP socket
> >>> file descriptors between the processes. This commit introduces
> >>> this logic using the IPC APIs.
> >
>
> On 2/4/2022 12:54 PM, Ciara Loftus wrote:
> > Secondary process support had been disabled for the AF_XDP PMD
> > because there was no logic in place to share the AF_XDP socket
> > file descriptors between the processes. This commit introduces
> > this logic using the IPC APIs.
> >
> > Since AF
>
> On Tue, Jan 25, 2022 at 07:20:43AM +, Ciara Loftus wrote:
> > AF_XDP support is deprecated in libbpf since v0.7.0 [1]. The
> > libxdp library now provides the functionality which once was in
> > libbpf and which the AF_XDP PMD relies on. This commit updates the
> > AF_XDP meson build to us
>
> On 10/14/2021 10:50 AM, Ciara Loftus wrote:
> > --- a/drivers/net/af_xdp/compat.h
> > +++ b/drivers/net/af_xdp/compat.h
> > @@ -2,9 +2,11 @@
> >* Copyright(c) 2020 Intel Corporation.
> >*/
> >
> > +#include
> > #include
> > #include
> > #include
> > +#include
>
> Hi Ciara,
> > > > >
> > > > > Doing basic operations like info_get or get_stats was broken
> > > > > in af_xdp PMD. The info_get would crash because dev->device
> > > > > was NULL in secondary process. Fix this by doing same initialization
> > > > > as af_packet and tap devices.
> > > > >
> > > > > The get_s
>
> On Mon, 20 Sep 2021 13:23:57 +0000
> "Loftus, Ciara" wrote:
>
> > > -Original Message-
> > > From: dev On Behalf Of Stephen Hemminger
> > > Sent: Friday 3 September 2021 17:15
> > > To: dev@dpdk.org
> > > C
> -Original Message-
> From: dev On Behalf Of Stephen Hemminger
> Sent: Friday 3 September 2021 17:15
> To: dev@dpdk.org
> Cc: Stephen Hemminger ;
> sta...@dpdk.org; xiaolong...@intel.com
> Subject: [dpdk-dev] [PATCH] net/af_xdp: fix support of secondary process
>
> Doing basic operati
>
> Call xsk_ring_prod__submit() before kick_tx() so that the kernel
> consumer sees the updated state of Tx ring. Otherwise, Tx packets are
> stuck in the ring until the next call to af_xdp_tx_zc().
>
> Fixes: d8a210774e1d ("net/af_xdp: support unaligned umem chunks")
> Cc: sta...@dpdk.org
>
>
>
> Call xsk_ring_prod__submit() before kick_tx() so that the kernel
> consumer sees the updated state of Tx ring. Otherwise, Tx packets are
> stuck in the ring until the next call to af_xdp_tx_zc().
>
> Fixes: d8a210774e1d ("net/af_xdp: support unaligned umem chunks")
> Cc: sta...@dpdk.org
>
>
>
> Hi,
>
> I can't compile dpdk-stable-20.11.1 on openSUSE Leap 15.3.
>
> kernel: 5.3.18-59.5-default
>
> Configuration options:
> Message:
> =
> Libraries Enabled
> =
>
> libs:
> kvargs, telemetry, eal, ring, rcu, mempool, mbuf, net,
> meter, e
> Subject: [PATCH v1 2/7] net/af_xdp: add power monitor support
>
> Implement support for .get_monitor_addr in AF_XDP driver.
>
> Signed-off-by: Anatoly Burakov
Thanks Anatoly. LGTM.
Acked-by: Ciara Loftus
> ---
> drivers/net/af_xdp/rte_eth_af_xdp.c | 25 +
> 1 file
>
> Implement support for .get_monitor_addr in AF_XDP driver.
>
> Signed-off-by: Anatoly Burakov
> ---
> drivers/net/af_xdp/rte_eth_af_xdp.c | 52 -
> 1 file changed, 37 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
> b/drivers/
> On 3/9/2021 10:19 AM, Ciara Loftus wrote:
> > This commit introduces support for preferred busy polling
> > to the AF_XDP PMD. This feature aims to improve single-core
> > performance for AF_XDP sockets under heavy load.
> >
> > A new vdev arg is introduced called 'busy_budget' whose default
> >
>
> On 3/9/2021 10:19 AM, Ciara Loftus wrote:
> > Prior to this commit, the maximum batch sizes for zero-copy and copy-
> mode
> > rx and copy-mode tx were set to 32. Apart from zero-copy tx, the user
> > could never rx/tx any more than 32 packets at a time and without
> inspecting
> > the code th
> >
> > On 2/24/2021 11:18 AM, Ciara Loftus wrote:
> > > This commit introduces support for preferred busy polling
> > > to the AF_XDP PMD. This feature aims to improve single-core
> > > performance for AF_XDP sockets under heavy load.
> > >
> > > A new vdev arg is introduced called 'busy_budget' w
>
> On 2/24/2021 11:18 AM, Ciara Loftus wrote:
> > This commit introduces support for preferred busy polling
> > to the AF_XDP PMD. This feature aims to improve single-core
> > performance for AF_XDP sockets under heavy load.
> >
> > A new vdev arg is introduced called 'busy_budget' whose default
>
> On 2/24/2021 11:18 AM, Ciara Loftus wrote:
> > Prior to this the max size was 32 which was unnecessarily
> > small.
>
> Can you please describe the impact? Why changed from 32 to 512?
> I assume this is to improve the performance but can you please explicitly
> document it in the commit log?
> Subject: [dpdk-dev] [PATCH][v4] net/af_xdp: optimize RX path by removing
> the unneeded allocation mbuf
>
> when receive packets, the max bunch number of mbuf are allocated
> if hardware does not receive the max bunch number packets, it
> will free redundancy mbuf, this is low performance
>
> s
>
> when receive packets, the max bunch number of mbuf are allocated
> if hardware does not receive the max bunch number packets, it
> will free redundancy mbuf, this is low performance
>
> so optimize rx performance, by allocating number of mbuf based on
> result of xsk_ring_cons__peek, to avoid
>
> On 11/12/2020 4:35 PM, Ciara Loftus wrote:
> > 'uint64_t' is used to hold pointers in multiple locations in the
> > copy-mode code (used for kernels before 5.4). For a 32-bit build
> > this assumption is wrong and results in build errors. This commit
> > replaces such instances of 'uint64_t' w
>
> On 10/14/2020 1:15 PM, Li,Rongqing wrote:
> >
> >
> >> -Original Message-----
> >> From: Loftus, Ciara [mailto:ciara.lof...@intel.com]
> >> Sent: Friday, October 02, 2020 12:24 AM
> >> To: Li,Rongqing
> >> Cc: dev@dpdk.org
>
> Hi All,
> There is a test plan for the performance tests of different
> scenarios
> with AF_XDP in the dpdk docs
> https://doc.dpdk.org/dts/test_plans/af_xdp_test_plan.html , but I am not
> able to find the test results of the same. Can anyone please help in sharing
> the resul
>
> 'uint64_t' is used to hold the pointer, for 32-bits build this
> assumption is wrong and giving following build error:
>
> rte_eth_af_xdp.c: In function ‘xdp_umem_configure’:
> rte_eth_af_xdp.c:970:15:
> error: cast to pointer from integer of different size
>[-Werror=int-to-po
> On 10/8/2020 10:17 AM, Ciara Loftus wrote:
> > Supporting this would require locks, which would impact the performance
> of
> > the more typical cases - xsks with different qids and netdevs.
> >
> > Signed-off-by: Ciara Loftus
> > Fixes: 74b46340e2d4 ("net/af_xdp: support shared UMEM")
>
> Hi C
>
> when receive packets, the max bunch number of mbuf are allocated
> if hardware does not receive the max bunch number packets, it
> will free redundancy mbuf, that is low-performance
>
> so optimize rx performance, by allocating number of mbuf based on
> result of xsk_ring_cons__peek, to avoid
>
> optimize rx performance, by allocating mbuf based on result
> of xsk_ring_cons__peek, to avoid to redundancy allocation,
> and free mbuf when receive packets
>
> Signed-off-by: Li RongQing
> Signed-off-by: Dongsheng Rong
> ---
> drivers/net/af_xdp/rte_eth_af_xdp.c | 64
> when receive packets, it is possible to fail to reserve
> fill queue, since buffer ring is shared between tx and rx,
> and maybe not available temporary. at last, both fill
> queue and rx queue are empty.
>
> then kernel side will be unable to receive packets due to
> empty fill queue, and dpdk
> >
> > Kernel v5.10 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 share
>
> af_xdp_rx_zc should always return the number of received packets,
> and negative value will be as number of received packets, and
> confuse the caller
>
> Fixes: d8a210774e1d ("net/af_xdp: support unaligned umem chunks")
> Cc: sta...@dpdk.org
> Signed-off-by: Li RongQing
> ---
> drivers/net
> >
> > The new 'xdp_prog=' vdev arg allows the user to specify the path
> to
> > a custom XDP program to be set on the device, instead of the default libbpf
> > one. The program must have an XSK_MAP of name 'xsks_map' which will
> > allow for the redirection of some packets to userspace and thus t
>
> 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 w
>
> On 8/11/2020 10:50 AM, Ciara Loftus wrote:
> > This RFC integrates shared UMEM support into the AF_XDP PMD. It is
> based on the
> > WIP kernel series [1] by Magnus Karlsson.
> >
> > Detailed information on the shared UMEM feature can be found in the final
> patch
> > in the aforementioned ser
>
> Vhost-user dequeue zero-copy support will be removed in
> 20.11. The only known user is OVS where the feature is
> still experimental, and has not received any update for
> several years. This feature faces reliability issues and
> is often conflicting with new features being implemented.
>
>
>
> On Fri, 12 Jun 2020 14:17:46 +
> Ciara Loftus wrote:
>
> > This commit makes some changes to the AF_XDP PMD in an effort to
> improve
> > its packet loss characteristics.
> >
> > 1. In the case of failed transmission due to inability to reserve a tx
> > descriptor, the PMD now pulls from
> Subject: Re: [dpdk-dev] [PATCH v3 3/3] net/af_xdp: fix maximum MTU value
>
> On 02/10, Ciara Loftus wrote:
> >The maximum MTU for af_xdp zero copy is equal to the page size less the
> >frame overhead introduced by AF_XDP (XDP HR = 256) and DPDK (frame
> headroom
> >= 320). The patch updates this
>
> The ring is used only by af_xdp pmd itself, so no need to support
> multi-producer and multi-consumer mode. This patch changes the ring
> to single-producer and single-consumer mode, which could yield better
> performance for addr enqueue and dequeue.
>
> Signed-off-by: Xiao Wang
LGTM.
I r
>
> Function kick_tx() has built-in detection on NEED_WAKEUP flag, so just
> call it directly, like elsewhere in the driver.
>
> Fixes: d8a210774e1d ("net/af_xdp: support unaligned umem chunks")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiao Wang
> ---
> drivers/net/af_xdp/rte_eth_af_xdp.c | 5
> > -Original Message-
> > From: Li, Xiaoyun
> > Sent: Thursday, December 26, 2019 2:46 PM
> > To: Zhang, Qi Z ; Xing, Beilei
> ;
> > Loftus, Ciara ; dev@dpdk.org
> > Cc: Li, Xiaoyun ; sta...@dpdk.org
> > Subject: [PATCH v3] net/i40
> > On Mon, 30 Sep 2019 16:42:04 +
> > Ciara Loftus wrote:
> >
> > > +/* drivers supported for the queue_irq option */
> > > +enum supported_drivers {
> > > + I40E_DRIVER,
> > > + IXGBE_DRIVER,
> > > + MLX5_DRIVER,
> > > + NUM_DRIVERS
> > > +};
> >
> > Anything device specific like this raises
> -Original Message-
> From: Stephen Hemminger
> Sent: Monday 30 September 2019 18:12
> To: Loftus, Ciara
> Cc: dev@dpdk.org; Ye, Xiaolong ; Laatz, Kevin
> ; Richardson, Bruce
> Subject: Re: [dpdk-dev] [PATCH v2 2/3] net/af_xdp: support pinning of IRQs
>
>
[snip]
> >+
> >+static void
> >+configure_irqs(struct pmd_internals *internals, uint16_t rx_queue_id)
> >+{
> >+int coreid = internals->queue_irqs[rx_queue_id];
> >+char driver[NAME_MAX];
> >+uint16_t netdev_qid = rx_queue_id + internals->start_queue_idx;
> >+regex_t r;
> >+int
>
> The kernel only consumes Tx packets if we have some Rx traffic on specified
> queue or we have called send(). So we need to issue a send() even when the
> allocation fails so that kernel will start to consume packets again.
>
> Commit 45bba02c95b0 ("net/af_xdp: support need wakeup feature") b
>
> Hi, Ciara
>
> Thanks for the patch, the performance number is quite impressive.
>
> On 08/29, Ciara Loftus wrote:
> >This patch enables the unaligned chunks feature for AF_XDP which allows
> >chunks to be placed at arbitrary places in the umem, as opposed to them
> >being required to be alig
> > Hi Ciara,
> >
> > I haven't tried this patch but have a question.
> >
> > On Thu, Aug 29, 2019 at 8:04 AM Ciara Loftus
> wrote:
> > >
> > > This patch enables the unaligned chunks feature for AF_XDP which
> > > allows chunks to be placed at arbitrary places in the umem, as
> > > opposed to the
> Hi Ciara,
>
> I haven't tried this patch but have a question.
>
> On Thu, Aug 29, 2019 at 8:04 AM Ciara Loftus wrote:
> >
> > This patch enables the unaligned chunks feature for AF_XDP which
> > allows chunks to be placed at arbitrary places in the umem, as opposed
> > to them being required t
>
> This patch enables the unaligned chunks feature for AF_XDP which allows
> chunks to be placed at arbitrary places in the umem, as opposed to them
> being required to be aligned to 2k. This allows for DPDK application
> mempools to be mapped directly into the umem and in turn enable zero
> copy
> > >
> > > Bala Sankaran writes:
> > >
> > > > Perfect!
> > > >
> > > > Thanks for the help.
> > > >
> > > > - Original Message -
> > > >> From: "Keith Wiles"
> > > >> To: "Bala Sankaran"
> > > >> Cc: us...@dpdk.org, "Aaron Conole"
> > > >> Sent: Thursday, July 5, 2018 11:41:46 AM
> >
>
> Bala Sankaran writes:
>
> > Perfect!
> >
> > Thanks for the help.
> >
> > - Original Message -
> >> From: "Keith Wiles"
> >> To: "Bala Sankaran"
> >> Cc: us...@dpdk.org, "Aaron Conole"
> >> Sent: Thursday, July 5, 2018 11:41:46 AM
> >> Subject: Re: [dpdk-users] Traffic doesn't for
>
> >
> > On 04/27/2018 04:19 PM, Ciara Loftus wrote:
> > > rte_eth_vhost_get_vid_from_port_id returns a value of 0 if called before
> > > the first call to the new_device callback. A vid value >=0 suggests the
> > > device is active which is not the case in this instance. Initialise vid
> > > to
>
> On 04/27/2018 04:19 PM, Ciara Loftus wrote:
> > rte_eth_vhost_get_vid_from_port_id returns a value of 0 if called before
> > the first call to the new_device callback. A vid value >=0 suggests the
> > device is active which is not the case in this instance. Initialise vid
> > to a negative val
...@corp.netease.com]
Sent: Wednesday, January 17, 2018 10:41 AM
To: Loftus, Ciara
Cc: dev@dpdk.org
Subject: About : Enable optional dequeue zero copy for vHost User
Hi Ciara,
I am tesing the function of "vHost dequeue zero copy" for vm2vm on a host,
and I have some problems:
1. The net
>
> Hi Junjie,
>
> On 12/13/2017 05:50 PM, Junjie Chen wrote:
> > This fix dequeue zero copy can not work with Qemu
> > version >= 2.7. Since from Qemu 2.7 virtio device
> > use virtio-1 protocol, the zero copy code path
> > forget to add offset to buffer address.
> >
> > Signed-off-by: Junjie Ch
> The queue allocation was changed, from allocating one queue-pair at a
> time to one queue at a time. Most of the changes have been done, but
> just with one being missed: the size of coping the old queue is still
> based on queue-pair at numa_realloc(), which leads to overwritten issue.
> As a re
>
> This patch implements the ops rx_queue_count for vhost PMD by adding
> a helper function rte_vhost_rx_queue_count in vhost lib.
>
> The ops ops rx_queue_count gets vhost RX queue avail count and helps
> to understand the queue fill level.
>
> Signed-off-by: Zhihong Wang
> ---
> drivers/net
SER_PROTOCOL_F_REPLY_ACK has to be disabled by default at the
> dpdk side in order to avoid the feature support of DPDK + qemu at
> the same time. if doing like that, MQ can works well. Once Qemu bugs
> have been fixed and upstreamed, we can enable it.
>
> Fixes: 73c8f9f69c6c(&quo
1 - 100 of 124 matches
Mail list logo
