Hi Ido,
> I've lots of good experience with ACL but can't make it work with u64 values
> I know it can be split to 2xu32 fields, but it makes it more complex to use
> and a wastes double number of fields (we hit the
> RTE_ACL_MAX_FIELDS 64 limit)
Wow, that's a lot of fields...
> According to
Minutes of Technical Board Meeting, 2022-April-20
Members Attending
---
-Aaron
-Bruce
-Hemant
-Honnappa
-Jerin
-Konstantin (chair)
-Maxime
-Stephen
-Thomas
NOTE: The technical board meetings are on every second Wednesday at
https://meet.jit.si/DPDK at 3 pm UTC.
Meetings
Hi Nithin,
> >> Enable Tx IPv4 checksum offload only when Tx inline crypto, lookaside
> >> crypto/protocol or cpu crypto is needed.
> >> For Tx Inline protocol offload, checksum computation
> >> is implicitly taken care by HW.
> >
> > The thing is that right now it is not stated explicitly that
>
> According to RFC791,the options may appear or not in datagrams.
> They must be implemented by all IP modules (host and gateways).
> What is optional is their transmission in any particular datagram,
> not their implementation.So we have to deal with it during the
> fragmenting process.Add some te
> Use HW parsed packet type when ethdev supports necessary protocols.
> If packet type is not supported, then register ethdev callbacks
> for parse packet in SW. This is better for performance as it
> effects fast path.
>
> Signed-off-by: Nithin Dabilpuram
> ---
> examples/ipsec-secgw/ipsec-se
Hi Nithin,
> Enable Tx IPv4 checksum offload only when Tx inline crypto, lookaside
> crypto/protocol or cpu crypto is needed.
> For Tx Inline protocol offload, checksum computation
> is implicitly taken care by HW.
The thing is that right now it is not stated explicitly that
RTE_SECURITY_ACTION_
Hi everyone,
First of all thanks Owen for stepping forward with this RFC.
Few thoughts on this subject below.
Konstantin
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, April 14, 2022 12:59 PM
> To: Ananyev, Konstantin
> Subject: FW: [PATCH v1 0/4
> A sequence lock (seqlock) is synchronization primitive which allows
> for data-race free, low-overhead, high-frequency reads, especially for
> data structures shared across many cores and which are updated
> relatively infrequently.
>
> A seqlock permits multiple parallel readers. The variant
>
> l3fwd-acl contains duplicate functions to l3fwd.
> For this reason we merge l3fwd-acl code into l3fwd
> with '--lookup acl' cmdline option to run ACL.
>
> Signed-off-by: Sean Morrissey
> ---
> V5:
> * remove undefined functions
> * remove unused struct members
> V4:
> * update maintainers
>
Hi Sean,
> >> +
> >> +/* Setup ACL context. 8< */
> > Looks like some typo within comments.
>
> I believe these characters are needed in the comments to state the start
> and end of the automated code snippets for the docs.
Ah ok, then please ignore đ
Hi Sean,
Few nits, that I didn't spot previously, pls see below.
> l3fwd-acl contains duplicate functions to l3fwd.
> For this reason we merge l3fwd-acl code into l3fwd
> with '--lookup acl' cmdline option to run ACL.
>
> Signed-off-by: Sean Morrissey
> ---
> MAINTAINERS
the patch to force
another run of test harness.
Aaron, is there any better way to deal with it?
Thanks
Konstantin
From: Huichao Cai
Sent: Wednesday, April 6, 2022 2:22 AM
To: Ananyev, Konstantin
Cc: dev@dpdk.org
Subject: Re:RE: [PATCH v5] ip_frag: add IPv4 options fragment and test data
Hi
Hi Sean,
My comments inline.
Thanks
Konstantin
> l3fwd-acl contains duplicate functions to l3fwd.
> For this reason we merge l3fwd-acl code into l3fwd
> with '--lookup acl' cmdline option to run ACL.
>
> Signed-off-by: Sean Morrissey
> ---
> V2:
> * add doc changes
> * minor code cleanup
> --
> > diff --git a/lib/eal/include/meson.build
> > b/lib/eal/include/meson.build
> > index 9700494816..48df5f1a21 100644
> > --- a/lib/eal/include/meson.build
> > +++ b/lib/eal/include/meson.build
> > @@ -36,6 +36,7 @@ headers += files(
> > Â Â 'rte_per_lcore.h',
>
Hi Sean,
> l3fwd-acl contains duplicate functions to l3fwd.
> For this reason we merge l3fwd-acl code into l3fwd
> with '--lookup acl' cmdline option to run ACL.
LGTM in general, some comments, mostly nits inline.
As one generic comment - doc update seems missing.
Thanks
Konstantin
> Signed-o
> >> diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
> >> index 9700494816..48df5f1a21 100644
> >> --- a/lib/eal/include/meson.build
> >> +++ b/lib/eal/include/meson.build
> >> @@ -36,6 +36,7 @@ headers += files(
> >> 'rte_per_lcore.h',
> >> 'rte_random.h
> diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
> index 9700494816..48df5f1a21 100644
> --- a/lib/eal/include/meson.build
> +++ b/lib/eal/include/meson.build
> @@ -36,6 +36,7 @@ headers += files(
> 'rte_per_lcore.h',
> 'rte_random.h',
> 'rte_recip
> According to RFC791,the options may appear or not in datagrams.
> They must be implemented by all IP modules (host and gateways).
> What is optional is their transmission in any particular datagram,
> not their implementation.So we have to deal with it during the
> fragmenting process.Add some
Hi Mattias,
>
> Would it make sense to have a seqlock implementation in DPDK?
>
> I think so, since it's a very useful synchronization primitive in data
> plane applications.
>
Agree, it might be useful.
As I remember rte_hash '_lf' functions do use something similar to seqlock,
but in hand-
> test_bpf_convert is being conditionally registered depending on the
> presence of RTE_HAS_LIBPCAP except the UT unconditionally lists it as a
> test to run.
>
> when the UT runs test_bpf_convert test-dpdk can't find the registration
> and assumes the DPDK_TEST environment variable hasn't been de
>
> test_bpf_convert is being conditionally registered depending on the
> presence of RTE_HAS_LIBPCAP except the UT unconditionally lists it as a
> test to run.
>
> when the UT runs test_bpf_convert test-dpdk can't find the registration
> and assumes the DPDK_TEST environment variable hasn't be
Hi Huichao,
> According to RFC791,the options may appear or not in datagrams.
> They must be implemented by all IP modules (host and gateways).
> What is optional is their transmission in any particular datagram,
> not their implementation.So we have to deal with it during the
> fragmenting proces
> Calls to rte_memcpy for 1 < n < 16 could result in unaligned
> loads/stores, which is undefined behaviour according to the C
> standard, and strict aliasing violations.
>
> The code was changed to use a packed structure that allows aliasing
> (using the __may_alias__ attribute) to perform the
> This patch fixes the stack buffer overflow error reported
> from AddressSanitizer.
> Function send_packetsx4() tries to access out of bound data
> from rte_mbuf and fill it into TX buffer even in the case
> where no pending packets (len = 0).
> Performance impact:- No
>
> ASAN error report:-
> =
Ho Huichao,
> According to RFC791,the options may appear or not in datagrams.
> They must be implemented by all IP modules (host and gateways).
> What is optional is their transmission in any particular datagram,
> not their implementation.So we have to deal with it during the
> fragmenting pro
> > > > > > > > > > > > > >> Or have a generic library for reading LPM entries.
> > > > > > > > > > > > > >> L3fwd is supposed
> > > > > > > > > > > > > >> to be as small as possible (it no longer is), and
> > > > > > > > > > > > > >> the real work should
> > > > > > > > > > > > > >> be done b
> On Thu, Feb 24, 2022 at 02:46:24PM +0100, Thomas Monjalon wrote:
> > 24/02/2022 12:06, Ananyev, Konstantin:
> > > > > > > > > > > >> Or have a generic library for reading LPM entries.
> > > > > > > > > > > >&
Hi Dmitry,
> 2022-02-21 00:56 (UTC+0300), Dmitry Kozlyuk:
> > 2022-02-09 13:57 (UTC+), Ananyev, Konstantin:
> > > > > Actually, please scrap that comment.
> > > > > Obviously it wouldn't work for static variables,
> > > > > and do
>
> 22/02/2022 16:13, Ananyev, Konstantin:
> >
> > > >
> > > > > > > > >> Or have a generic library for reading LPM entries. L3fwd is
> > > > > > > > >> supposed
> > > > >
> >
> > > > > > >> Or have a generic library for reading LPM entries. L3fwd is
> > > > > > >> supposed
> > > > > > >> to be as small as possible (it no longer is), and the real work
> > > > > > >> should
> > > > > > >> be done by libraries to make it easier to build other
> > > > > > >> appl
> > > > >> Or have a generic library for reading LPM entries. L3fwd is supposed
> > > > >> to be as small as possible (it no longer is), and the real work
> > > > >> should
> > > > >> be done by libraries to make it easier to build other applications.
> > > > >
> > > > > I never heard users ask
Hi Huichao,
> According to RFC791,the options may appear or not in datagrams.
> They must be implemented by all IP modules (host and gateways).
> What is optional is their transmission in any particular datagram,
> not their implementation.So we have to deal with it during the
> fragmenting proce
> Enable Tx IPv4 checksum offload only when Tx inline crypto is needed.
> In other cases such as Tx Inline protocol offload, checksum computation
> is implicitly taken care by HW. The advantage of having only necessary
> offloads enabled is that Tx burst function can be as light as possible.
I
> >> Enable Tx IPv4 checksum offload only when Tx inline crypto is needed.
> >> In other cases such as Tx Inline protocol offload, checksum computation
> >> is implicitly taken care by HW.
> >
> > Why is that?
> > These is two separate HW offload and user has to enable each of them
> > explicitly
Hi Luc,
> > Indeed it looks like a problem.
> > Thanks for pointing it out.
> > Was able to reproduce it with gcc 11 (clang 13 seems fine).
> > Actually, adding ' __attribute__ ((__may_alias__))' for both dst and src
> > didn't quire the problem.
>
> __may_alias__ works if it's applied to a typ
> diff --git a/lib/net/rte_net.h b/lib/net/rte_net.h
> index 53a7f4d360..56611fc8f9 100644
> --- a/lib/net/rte_net.h
> +++ b/lib/net/rte_net.h
> @@ -12,7 +12,6 @@ extern "C" {
> #include
> #include
> #include
> -#include
>
That seems strange, why to remove header definition from rte_net.
> > Not sure I understand the problem you are referring to.
> > Are you saying that original rte_memcpy() code breaks strict aliasing?
> > If so, could you point where exactly?
>
> As far as I understand, yes, it does break strict aliasing. For
> example, in the following line:
>
> *(uint64_t *)d
> If conversion of cBPF to eBPF fails (in rte_bpf_convert)
> then the test should not try and print the result.
>
> Coverity issue: 373661
> Fixes: 2eccf6afbea9 ("bpf: add function to convert classic BPF to DPDK BPF")
> Signed-off-by: Stephen Hemminger
> ---
> app/test/test_bpf.c | 6 --
>
Hi Huichao
>>As a nit, why not 'uint8_t *', to keep style the same through all file?
>Yes,I can use 'uint8_t *.Thank you for your correction.
>
>>We already done such calculation in rte_ipv4_fragment_packet(),
>>so can re-use header_len value here.
>Yes,I can re-use header_len.Thank you for your
Hi Luc,
> > > Calls to rte_memcpy_generic could result in unaligned loads/stores for
> > > 1 < n < 16. This is undefined behavior according to the C standard,
> > > and it gets flagged by the clang undefined behavior sanitizer.
> > >
> > > rte_memcpy_generic is called with unaligned src and dst ad
> C++ does not have automatic casting to/from void pointers, so need
> explicit cast if header is to be included in C++ code
>
> Fixes: f901d9c82688 ("ipsec: add helpers to group completed crypto-ops")
> Cc: konstantin.anan...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bruce Richardson
>
> According to RFC791,the options may appear or not in datagrams.
> They must be implemented by all IP modules (host and gateways).
> What is optional is their transmission in any particular datagram,
> not their implementation.So we have to deal with it during the
> fragmenting process.Add s
> > Actually, please scrap that comment.
> > Obviously it wouldn't work for static variables,
> > and doesn't make much sense.
> > Though few thoughts remain:
> > for posix we probably don't need an indirection and
> > rte_thread_mutex can be just typedef of pthread_mutex_t.
> > also for posix we
> On Mon, Feb 07, 2022 at 04:02:54PM +0000, Ananyev, Konstantin wrote:
> > > Add functions for mutex init, destroy, lock, unlock, trylock.
> > >
> > > Windows does not have a static initializer. Initialization
> > > is only done through Initia
> > >> Or have a generic library for reading LPM entries. L3fwd is supposed
> > >> to be as small as possible (it no longer is), and the real work should
> > >> be done by libraries to make it easier to build other applications.
> > >
> > > I never heard users ask about such thing,
> > > but if
> Supplement define guards to prevent multiple inclusion.
> It should noted that there is an exceptional case:
> lib/acl/acl_run_avx512_common.h is designed to be included
> several times.
>
> Signed-off-by: Weiguo Li
> ---
> lib/acl/acl_run_altivec.h | 5 +
> lib/acl/acl_run_avx2.h
> > > > This patchset introduces config file support for l3fwd
> > > > and its lookup methods LPM, FIB, and EM, similar to
> > > > that of l3fwd-acl. This allows for route rules to be
> > > > defined in configuration files and edited there instead
> > > > of in each of the lookup methods hardcode
> > +
> > +/**
> > + * Thread mutex representation.
> > + */
> > +typedef struct rte_thread_mutex_tag {
> > + void *mutex_id; /**< mutex identifier */
> > +} rte_thread_mutex;
>
> I wonder can't we have something like that instead:
>
> for posix:
> typedef pthread_mutex_t rte_thread_mutex_t
> Add functions for mutex init, destroy, lock, unlock, trylock.
>
> Windows does not have a static initializer. Initialization
> is only done through InitializeCriticalSection(). To overcome this,
> RTE_INIT_MUTEX macro is added to replace static initialization
> of mutexes. The macro calls rte_th
> Enable Tx IPv4 checksum offload only when Tx inline crypto is needed.
> In other cases such as Tx Inline protocol offload, checksum computation
> is implicitly taken care by HW.
Why is that?
These is two separate HW offload and user has to enable each of them explicitly.
Also we can TX clear-t
> > This patchset introduces config file support for l3fwd
> > and its lookup methods LPM, FIB, and EM, similar to
> > that of l3fwd-acl. This allows for route rules to be
> > defined in configuration files and edited there instead
> > of in each of the lookup methods hardcoded route tables.
> >
>
> On Fri, Feb 04, 2022 at 07:21:10PM +, Ananyev, Konstantin wrote:
> > > Implement thread attributes for:
> > > * thread affinity
> > > * thread priority
> > > Implement functions for managing thread attributes.
> > >
> > >
> Implement thread attributes for:
> * thread affinity
> * thread priority
> Implement functions for managing thread attributes.
>
> Priority is represented through an enum that allows for two levels:
> - RTE_THREAD_PRIORITY_NORMAL
> - RTE_THREAD_PRIORITY_REALTIME_CRITICAL
>
> Affinit
> Use a portable, type-safe representation for the thread identifier.
> Add functions for comparing thread ids and obtaining the thread id
> for the current thread.
>
> Signed-off-by: Narcisa Vasile
> ---
> lib/eal/common/meson.build| 1 +
> lib/eal/{unix => common}/rte_thread.c | 5
> Calls to rte_memcpy_generic could result in unaligned loads/stores for
> 1 < n < 16. This is undefined behavior according to the C standard,
> and it gets flagged by the clang undefined behavior sanitizer.
>
> rte_memcpy_generic is called with unaligned src and dst addresses.
> When 1 < n < 16
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > Sent: Tuesday, 18 January 2022 17.54
> > >
> > > [quick summary: ethdev API to bypass mempool]
> > >
> > > 18/01/2022 16:51, Ferruh Yigit:
> > > > On 12/28/2021 6:55 AM, Feifei Wang wrote:
> > > > > Morten Brørup :
> > > > >> The patc
> If we don't memset acl result array before matching,
> we can get arbitrary dirty data from memory.
I don't think it is the case.
acl_classify() on successful completion will always populate result array.
The only exception - user provided ivalid input parameters, or acl ctx is not
build, et
> > On Tue, 2021-12-14 at 14:12 +, Ronan Randles wrote:
> > > This patchset introduces a Gen library for DPDK. This library provides an
> > > easy
> > > way to generate traffic in order to test software based network
> > > components.
> > >
> > > This library enables the basic functionality
>
>
> Hi Dharmik,
> > >
> > >>>
> > Current mempool per core cache implementation stores pointers to mbufs
> > On 64b architectures, each pointer consumes 8B
> > This patch replaces it with index-based implementation,
> > where in each buffer is addressed by (pool base addre
Hi Dharmik,
> >
> >>>
> Current mempool per core cache implementation stores pointers to mbufs
> On 64b architectures, each pointer consumes 8B
> This patch replaces it with index-based implementation,
> where in each buffer is addressed by (pool base address + index)
> I
>
> Some drivers bypass the mbuf/mempool library functions, to manipulate the
> mempool cache directly for improved performance.
>
> Specifically, the AVX512 implementation of some of the Intel PMDs copy an
> array of objects from the cache to a field in an array of some
> structure, i.e. it
would
verify packet checksum and set RTE_MBUF_F_RX_*_CKSUM_* for it.
From: Usama Nadeem
Sent: Friday, January 14, 2022 9:30 AM
To: Ananyev, Konstantin
Cc: tho...@monjalon.net; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v4] examples/l3fwd: ipv4 and udp/tcp cksum
verification through software
Hello
>
> > From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
> > Sent: Friday, 14 January 2022 11.54
> >
> > > From: Morten Brørup
> > > Sent: Friday, January 14, 2022 9:54 AM
> > >
> > > > From: Bruce Richardson [mailto:
> -Original Message-
> From: Morten Brørup
> Sent: Friday, January 14, 2022 9:54 AM
> To: Richardson, Bruce
> Cc: Jan Viktorin ; Ruifeng Wang
> ; David Christensen ;
> Ananyev, Konstantin ; dev@dpdk.org
> Subject: RE: rte_memcpy alignment
>
> > > > >
> > > > > +/**
> > > > > + * In case of IP reassembly offload failure, ol_flags in mbuf will
> > > > > be set
> > > > > + * with RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE and packets will
> > be
> > > > returned
> > > > > + * without alteration. The application can retrieve the attached
> > > > > > > Another question - if we have reassembly_conf_set() would it make
> > sense
> > > to
> > > > > > > have also reassembly_conf_get?
> > > > > > > So user can retrieve current ip_reassembly config values?
> > > > > > >
> > > > > > The set/supported values can be retrieved using rte_et
Hi Akhil,
> Hi Konstantin,
> > > > Hardware IP reassembly may be incomplete for multiple reasons like
> > > > reassembly timeout reached, duplicate fragments, etc.
> > > > To save application cycles to process these packets again, a new
> > > > mbuf ol_flag (RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE)
Hi Dharmik,
> >
> >> Current mempool per core cache implementation stores pointers to mbufs
> >> On 64b architectures, each pointer consumes 8B
> >> This patch replaces it with index-based implementation,
> >> where in each buffer is addressed by (pool base address + index)
> >> It reduces the a
> > > > Another question - if we have reassembly_conf_set() would it make sense
> > > > to
> > > > have also reassembly_conf_get?
> > > > So user can retrieve current ip_reassembly config values?
> > > >
> > > The set/supported values can be retrieved using rte_eth_dev_info ::
> > reass_capa
>
> >
> > > Hardware IP reassembly may be incomplete for multiple reasons like
> > > reassembly timeout reached, duplicate fragments, etc.
> > > To save application cycles to process these packets again, a new
> > > mbuf ol_flag (RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE) is added to
> > > show that th
> > > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> > > index d9a03f12f9..ecc6c1fe37 100644
> > > --- a/lib/ethdev/rte_ethdev.c
> > > +++ b/lib/ethdev/rte_ethdev.c
> > > @@ -6473,6 +6473,36 @@ rte_eth_rx_metadata_negotiate(uint16_t port_id,
> > uint64_t *features)
> > >
> Hardware IP reassembly may be incomplete for multiple reasons like
> reassembly timeout reached, duplicate fragments, etc.
> To save application cycles to process these packets again, a new
> mbuf ol_flag (RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE) is added to
> show that the mbuf received is not r
> A new ethernet device op is added to give application control over
> the IP reassembly configuration. This operation is an optional
> call from the application, default values are set by PMD and
> exposed via rte_eth_dev_info.
> Application should always first retreive the capabilities from
>
> IP Reassembly is a costly operation if it is done in software.
> The operation becomes even more costlier if IP fragmants are encrypted.
> However, if it is offloaded to HW, it can considerably save application
> cycles.
>
> Hence, a new offload RTE_ETH_RX_OFFLOAD_IP_REASSEMBLY is introduced
> Current mempool per core cache implementation stores pointers to mbufs
> On 64b architectures, each pointer consumes 8B
> This patch replaces it with index-based implementation,
> where in each buffer is addressed by (pool base address + index)
> It reduces the amount of memory/cache require
> When enqueueing/dequeueing to/from the ring we try to optimize by manual
> loop unrolling. The check for this optimization looks like:
>
> if (likely(idx + n < size)) {
>
> where 'idx' points to the first usable element (empty slot for enqueue,
> data for dequeue). The correct compariso
> - Add RING_F_EXACT_SZ description to rte_ring_init and
> rte_ring_create param comments.
> - Fix ring size comments.
>
> Signed-off-by: Robert Sanford
> ---
Acked-by: Konstantin Ananyev
> 2.7.4
> The error value returned by rte_ring_create_elem() should be positive
> integers. However, if the rte_ring_get_memsize_elem() function fails,
> a negative number is returned and is directly used as the return value.
> As a result, this will cause the external call to check the return
> value to f
> Add support to define ipv4 and ipv6 forwarding tables
> from reading from a config file for EM with a format
> similar to l3fwd-acl one.
>
> With the removal of the hardcoded route tables for IPv4
> and IPv6 from 'l3fwd_em', these routes have been moved
> to a separate default config file fo
Hi Sean,
Few comments below.
> Add support to define ipv4 and ipv6 forwarding tables
> from reading from a config file for EM with a format
> similar to l3fwd-acl one.
>
> With the removal of the hardcoded route tables for IPv4
> and IPv6 from 'l3fwd_em', these routes have been moved
> to a se
> Add support to define ipv4 and ipv6 forwarding tables
> from reading from a config file for LPM and FIB,
> with format similar to l3fwd-acl one.
>
> With the removal of the hardcoded route tables for IPv4
> and IPv6, these routes have been moved to a separate
> default config file for use with L
> Parameters count and esize are both unsigned int, and their product can
> legally exceed unsigned int and lead to runtime access violation.
>
> Fixes: cc4b218790f6 ("ring: support configurable element size")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Zhihong Wang
> ---
> lib/ring/rte_ring.c
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Wednesday, 15 December 2021 04.21
> >
> > On Wed, 15 Dec 2021 01:06:14 +
> > "Ananyev, Konstantin" wrote:
> >
> > > > -Original Message-
> > &
> -Original Message-
> From: Morten Brørup
> Sent: Tuesday, December 14, 2021 5:31 PM
> To: Randles, Ronan ; dev@dpdk.org
> Cc: Van Haaren, Harry
> Subject: RE: [PATCH 02/12] net: add function to pretty print IPv4
>
> > From: Ronan Randles [mailto:ronan.rand...@intel.com]
> > Sent: Tu
> -Original Message-
> From: Richardson, Bruce
> Sent: Monday, December 6, 2021 9:17 AM
> To: Lewis Donzis
> Cc: dev ; Wang, Yong ; Ananyev, Konstantin
>
> Subject: Re: vmxnet3 no longer functional on DPDK 21.11
>
> On Sun, Dec 05, 2021 at 07:52:33P
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Thursday, 2 December 2021 08.19
> >
> > 01/12/2021 22:37, Tyler Retzlaff:
> > > On Wed, Nov 24, 2021 at 06:04:56PM +, Bruce Richardson wrote:
> > > > if (ret < 0 && rte_errno == EAGAIN)
> > >
> > > i only urge that this be ex
I didn't look at it in detail yet,
just wonder would be real gain in terms of space?
From: Huichao Cai
Sent: Thursday, December 2, 2021 11:39 AM
To: Dariusz Sosnowski
Cc: Ananyev, Konstantin ; dev@dpdk.org
Subject: Re:Re: [PATCH] ip_frag: add IPv4 options fragment and unit test data
If op
1.7 GHz SPR, 'D' stepping
1 DSA device, 1 WQ (size=128, 1 engine, mode="dedicated", type="kernel",
name="dmaengine")
io_uring-bench with some mods:
1 thread, 1 io_uring context (sq_ring=64,cq_ring=128), random reads over one
1GB file on tmpfs
Without touching data in user-space:
> >>
>
> >>
> > On Wed, 17 Nov 2021 03:04:59 +
> >>
>
> >> This patch introduces GPU memory in testpmd through the gpudev library.
> >>
>
> >>
> >> Testpmd can be used for network benchmarks when using GPU memory
> >>
>
> >>
> >> instead of regular CPU memor
> Could you, please, set "Author" correctly - "Elena Agostini
> "?
> Otherwise, we see in the git log:
>
> "Author: eagostini "
>
> Compare with:
> "Author: Bing Zhao "
> "Author: Viacheslav Ovsiienko "
>
> Also, please, see the codestyle issues, too many code lines far beyond 100
> chars.
>
> hi folks,
>
> I don't understand the text of this change. would you mind explaining?
>
> commit f9bdee267ab84fd12dc288419aba341310b6ae08
> Author: Konstantin Ananyev
> Date: Wed Oct 13 14:37:04 2021 +0100
> ethdev: hide internal structures
>
> +* ethdev: Made ``rte_eth_dev`
> From: Rohit Raj
>
> l3fwd uses mbufs with 2KB data size. If we enable jumbo packets, it is
> not able to store packets with size greater than 2KB, hence these
> packets are dropped.
>
> This patch fixes this issue by enabling scatter for jumbo packet, if
> it is supported by NIC.
>
> If sc
>
> >
> >
> >
> > Hi Jerin,
> >
> > > > Minutes of Technical Board Meeting, 2021-Oct-27
> > > >
> > > > Members Attending
> > > > ---
> > > > -Aaron
> > > > -Ferruh
> > > > -Hemant
> > > > -Honnappa
> > > > -Jerin
> > > > -Kevin
> > > > -Konstantin (Chair)
> > > > -Maxime
Hi Jerin,
> > Minutes of Technical Board Meeting, 2021-Oct-27
> >
> > Members Attending
> > ---
> > -Aaron
> > -Ferruh
> > -Hemant
> > -Honnappa
> > -Jerin
> > -Kevin
> > -Konstantin (Chair)
> > -Maxime
> > -Stephen
> > -Thomas
> >
> > NOTE: The technical board meetings e
Hi Ferruh,
> >> 22/10/2021 23:14, Bing Zhao:
> >>> In the function "eth_dev_fp_ops_reset", a structure assignment
> >>> operation is used to reset one queue's callback functions, etc., but
> >>> it is not thread safe.
> >>>
> >>> The structure assignment is not atomic, a lot of instructions will
> checks if ipv4 and udptcp cksum offload capability available
> If not available, cksum is verified through software
> If cksum is corrupt, packet is dropped, rest of the packets
> are forwarded back.
>From what I see right now l3fwd:
a) enables HW RX cksum offload
b) simply ignores HW pro
Hi Ben,
I also donât think 64 is a common case here.
For such cases we probably should think up some different approach for the
reassembly table.
From: Ben Magistro
Sent: Wednesday, November 3, 2021 2:38 PM
To: Ananyev, Konstantin
Cc: Richardson, Bruce ; dev@dpdk.org;
ben.magis
> On Tue, 2 Nov 2021 10:54:59 +
> "Ananyev, Konstantin" wrote:
>
> > > > rte_bpf_convert() implementation depends on libpcap.
> > > > Right now it is defined only when this library is installed and
> > > > RTE_PORT_PCAP is de
Minutes of Technical Board Meeting, 2021-Oct-27
Members Attending
---
-Aaron
-Ferruh
-Hemant
-Honnappa
-Jerin
-Kevin
-Konstantin (Chair)
-Maxime
-Stephen
-Thomas
NOTE: The technical board meetings every second Wednesday at
https://meet.jit.si/DPDK at 3 pm UTC.
Meetings are
> > > > > On Fri, Oct 29, 2021 at 09:48:30AM -0400, Ben Magistro wrote:
> > > > > > With the transition to meson, what is the best way to provide
> > > > > > custom values
> > > > > > to parameters in rte_config.h? When using makefiles, (from memory,
> > > > > > I
> > > > > > think) we used co
1 - 100 of 3104 matches
Mail list logo
