Current implementation of rte_ipv4_fragment_packet() doesn’t take
into account offset and flag values of the given packet, but blindly
assumes they are always zero (original packet is not fragmented).
According to RFC791, fragment and flag values for new fragment
should take into account values pro
From: Narcisa Vasile
EAL thread API
**Problem Statement**
DPDK currently uses the pthread interface to create and manage threads.
Windows does not support the POSIX thread programming model,
so it currently
relies on a header file that hides the Windows calls under
pthread matched interfaces. Gi
From: Narcisa Vasile
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_threa
From: Narcisa Vasile
Add function to translate Windows error codes to
errno-style error codes. The possible return values are chosen
so that we have as much semantical compatibility between platforms as
possible.
Signed-off-by: Narcisa Vasile
---
lib/eal/common/rte_thread.c | 6 +--
lib/eal/
From: Narcisa Vasile
Implement functions for getting/setting thread affinity.
Threads can be pinned to specific cores by setting their
affinity attribute.
Signed-off-by: Narcisa Vasile
Signed-off-by: Dmitry Malloy
---
lib/eal/common/rte_thread.c | 16
lib/eal/include/rte_thread.h |
From: Narcisa Vasile
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
From: Narcisa Vasile
Add functions for setting and getting the priority of a thread.
Priorities on multiple platforms are similarly determined by
a priority value and a priority class/policy.
On Linux, the following mapping is created:
RTE_THREAD_PRIORITY_NORMAL corresponds to
* policy SCHED_OTH
From: Narcisa Vasile
Add functions for mutex init, destroy, lock, unlock, trylock.
Add RTE_STATIC_MUTEX macro to replace static initialization
of mutexes.
Windows does not have a static initializer.
Initialization is only done through InitializeCriticalSection().
The RTE_STATIC_MUTEX calls into
From: Narcisa Vasile
Add functions for barrier init, destroy, wait.
A portable type is used to represent a barrier identifier.
The rte_thread_barrier_wait() function returns the same value
on all platforms.
Signed-off-by: Narcisa Vasile
---
lib/eal/common/rte_thread.c | 61 ++
From: Narcisa Vasile
Add functions for thread creation, joining, detaching.
The *rte_thread_create()* function can optionally receive
an rte_thread_attr_t object that will cause the thread to be
created with the affinity and priority described by the
attributes object. If no rte_thread_attr_t is
From: Narcisa Vasile
As a new API for threading is introduced,
a set of unit tests have been added to test the new interface.
The tests verify that:
* mutexes and barriers behave as expected
* thread properties are applied correctly
* the thread id is retrieved correctly
* thread creation/des
From: Chengchang Tang
For different capabilities, we declare different macro functions to
determine whether the capabilities are supported.
This patch declare a unified macro function to judge capabilities.
Signed-off-by: Chengchang Tang
Signed-off-by: Min Hu (Connor)
---
drivers/net/hns3/hn
From: Pavan Nikhilesh
Minimum supported interval should now be retrieved from
mailbox based on the clock source and clock frequency.
Signed-off-by: Pavan Nikhilesh
---
v4:
- Rebase on master, fix NULL checks.
v3:
- Add new mbox interface.
v2:
- Fixed devargs parsing and rebased.
drivers/commo
From: Pavan Nikhilesh
Add external clock support for cnxk timer adapter.
External clock mapping is as follows:
RTE_EVENT_TIMER_ADAPTER_EXT_CLK0 = TIM_CLK_SRC_10NS,
RTE_EVENT_TIMER_ADAPTER_EXT_CLK1 = TIM_CLK_SRC_GPIO,
RTE_EVENT_TIMER_ADAPTER_EXT_CLK2 = TIM_CLK_SRC_PTP,
RTE_EVENT_TIMER_ADAPTER_EXT
From: Huisong Li
When configuring DCB, testpmd retains the rx_mode/tx_mode configuration in
rte_port->dev_conf. But some configurations, such as the link_speed, were
not saved if it were set before configuring DCB.
Fixes: 1a572499beb6 ("app/testpmd: setup DCB forwarding based on traffic class")
> -Original Message-
> From: dev On Behalf Of Zhang, RobinX
> Sent: Tuesday, September 28, 2021 6:36 PM
> To: Kevin Traynor ; dev@dpdk.org
> Cc: Xing, Beilei ; Guo, Junfeng
> ; Yang, SteveX
> Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix remove MAC/VLAN addresses
> error
>
> Hi,
>
> >
This patch set contains six patch for new add dmadev.
Chengwen Feng (6):
dmadev: introduce DMA device library
dmadev: add control plane API support
dmadev: add data plane API support
dmadev: add multi-process support
dma/skeleton: introduce skeleton dmadev driver
app/test: add dmadev A
This patch add control plane API for dmadev.
Signed-off-by: Chengwen Feng
Acked-by: Bruce Richardson
Acked-by: Morten Brørup
Reviewed-by: Kevin Laatz
Reviewed-by: Conor Walsh
---
doc/guides/prog_guide/dmadev.rst | 38 ++
doc/guides/rel_notes/release_21_11.rst | 1 +
lib/dmadev/rte_d
The 'dmadev' is a generic type of DMA device.
This patch introduce the 'dmadev' device allocation functions.
The infrastructure is prepared to welcome drivers in drivers/dma/
Signed-off-by: Chengwen Feng
Acked-by: Bruce Richardson
Acked-by: Morten Brørup
Acked-by: Jerin Jacob
Reviewed-by: Ke
This patch add multi-process support for dmadev.
Signed-off-by: Chengwen Feng
Acked-by: Bruce Richardson
Acked-by: Morten Brørup
Reviewed-by: Kevin Laatz
Reviewed-by: Conor Walsh
---
doc/guides/rel_notes/release_21_11.rst | 1 +
lib/dmadev/rte_dmadev.c| 176
This patch add data plane API for dmadev.
Signed-off-by: Chengwen Feng
Acked-by: Bruce Richardson
Acked-by: Morten Brørup
Reviewed-by: Kevin Laatz
Reviewed-by: Conor Walsh
---
doc/guides/prog_guide/dmadev.rst | 22 ++
doc/guides/rel_notes/release_21_11.rst | 2 +-
lib/dmadev/meson.b
Skeleton dmadevice driver, on the lines of rawdev skeleton, is for
showcasing of the dmadev library.
Design of skeleton involves a virtual device which is plugged into VDEV
bus on initialization.
Also, enable compilation of dmadev skeleton drivers.
Signed-off-by: Chengwen Feng
Reviewed-by: Kevi
This patch add dmadev API test which based on 'dma_skeleton' vdev. The
test cases could be executed using 'dmadev_autotest' command in test
framework.
Signed-off-by: Chengwen Feng
Signed-off-by: Bruce Richardson
Reviewed-by: Kevin Laatz
Reviewed-by: Conor Walsh
---
MAINTAINERS
> -Original Message-
> From: Yu, DapengX
> Sent: Saturday, October 9, 2021 11:25 AM
> To: Wu, Jingjing ; Xing, Beilei
> ;
> Richardson, Bruce ; Ananyev, Konstantin
>
> Cc: dev@dpdk.org; Zhang, Qi Z ; Yigit, Ferruh
> ; Yu, DapengX ;
> sta...@dpdk.org
> Subject: [PATCH v2] net/iavf: fix
Hi, Thomas,
The dev->data->mac_addrs[0] will be changed to a new MAC address when
applications modify
the default MAC address by rte_eth_dev_default_mac_addr_set() API.
However, If the new default
MAC address has been added as a non-default MAC address by
rte_eth_dev_mac_addr_add() API, the
rt
This patch follows the idea of Konstantin, and introduces rte_dma_fp_object to
hide
implementation detail.
This change modify the first parameter of drivers's dataplane interface: from
'struct rte_dma_dev *dev' to 'void *dev_private'.
On 2021/10/9 17:33, Chengwen Feng wrote:
> This patch add data
在 2021/10/8 0:56, Ferruh Yigit 写道:
Setting MTU bigger than RTE_ETHER_MTU requires the jumbo frame support,
and application should enable the jumbo frame offload support for it.
When jumbo frame offload is not enabled by application, but MTU bigger
than RTE_ETHER_MTU is requested there are two
在 2021/10/9 1:11, Ananyev, Konstantin 写道:
Removing 'DEV_RX_OFFLOAD_JUMBO_FRAME' offload flag.
Instead of drivers announce this capability, application can deduct the
capability by checking reported 'dev_info.max_mtu' or
'dev_info.max_rx_pktlen'.
And instead of application setting this flag
Hi, Ferruh
在 2021/10/8 0:56, Ferruh Yigit 写道:
Both 'rte_eth_dev_configure()' & 'rte_eth_dev_set_mtu()' sets MTU but
have slightly different checks. Like one checks min MTU against
RTE_ETHER_MIN_MTU and other RTE_ETHER_MIN_LEN.
Checks moved into common function to unify the checks. Also this has
On 2021/10/7 19:27, Konstantin Ananyev wrote:
> Copy public function pointers (rx_pkt_burst(), etc.) and related
> pointers to internal data from rte_eth_dev structure into a
> separate flat array. That array will remain in a public header.
> The intention here is to make rte_eth_dev and related st
This patch enables building the e1000 driver for Windows.
I tested using two Windows VM on top of VMware Fusion,
creating two e1000 devices with device ID 0x10D3 (8274L),
verifying rx/tx works correctly using dpdk-testpmd.exe
rxonly and txonly mode.
Signed-off-by: William Tu
Acked-by: Haiyue Wang
> > +Windows Configuration
> > +-
> > +
> > +- Follow the :doc:`guide for Windows <../windows_gsg/run_apps>`
> > + to setup the basic DPDK environment.
> > +
> > +- Identify the Intel\ |reg| Ethernet adapter.
> > +
> > +- To load NetUIO driver, follow the steps mentioned in `dp
2021-10-09 09:31 (UTC-0700), William Tu:
> [...]
> * @Dmitry: I think it's better keep the doc for
> people to reference NetUIO setup.
I won't insist, especially since Intel is OK with this.
I've sent a patch to put the link in Windows GSG
so that we won't need to repeat it for each PMD:
http://
https://bugs.dpdk.org/show_bug.cgi?id=798
Asaf Penso (as...@nvidia.com) changed:
What|Removed |Added
Status|IN_PROGRESS |RESOLVED
Resolution|---
On 10/8/2021 5:14 PM, William Tu wrote:
On Fri, Oct 8, 2021 at 5:02 PM Kadam, Pallavi wrote:
On 10/8/2021 6:53 AM, William Tu wrote:
This patch enables building the e1000 driver for Windows.
I tested using two Windows VM on top of VMware Fusion,
creating two e1000 devices with device ID 0x1
On 10/8/2021 2:11 PM, Dmitry Kozlyuk wrote:
Windows GSG included a section only on virt2phys driver installation,
but not on NetUIO. The content of the section duplicated documentation
in dpdk-kmods, but contained no links to it, only a reference.
Add subsections for virt2phys and NetUIO, expl
2021-10-09 12:38 (UTC-0700), Kadam, Pallavi:
> On 10/8/2021 2:11 PM, Dmitry Kozlyuk wrote:
> > [...]
> > +virt2phys
> > +~
> >
> > -1. From Device Manager, Action menu, select "Add legacy hardware".
> > -2. It will launch the "Add Hardware Wizard". Click "Next".
> > -3. Select second opt
As per RFC [1], action PORT_ID appears to be ambiguous. Its name suggests
that matching traffic be sent to the ethdev with the specified ID, that
is, to the application. However, in Open vSwitch, the action is used to
send traffic to a remote entity represented by the given port, that is,
in the op
For use in "transfer" flows. Supposed to match traffic
entering the embedded switch from the given ethdev.
Must not be combined with direction attributes.
Signed-off-by: Ivan Malov
---
app/test-pmd/cmdline_flow.c | 27 ++
doc/guides/prog_guide/rte_flow.rst | 59
For use in "transfer" flows. Supposed to match traffic entering the
embedded switch from the entity represented by the given ethdev.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.
Must not be combined with direction attri
For use in "transfer" flows. Supposed to send matching traffic to
the given ethdev (to the application), at embedded switch level.
Signed-off-by: Ivan Malov
---
app/test-pmd/cmdline_flow.c | 26 ++
doc/guides/prog_guide/rte_flow.rst | 56 +
do
For use in "transfer" flows. Supposed to send matching traffic to the
entity represented by the given ethdev, at embedded switch level.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.
Signed-off-by: Ivan Malov
---
app/te
Attributes "ingress" and "egress" can only apply unambiguosly
to non-"transfer" flows. In "transfer" flows, the standpoint
is effectively shifted to the embedded switch. There can be
many different endpoints connected to the switch, so the
use of "ingress" / "egress" does not shed light on which
en
PF, VF and PHY_PORT require that applications have extra
knowledge of the underlying NIC and thus are hard to use.
Also, the corresponding items depend on the direction
attribute (ingress / egress), which complicates their
use in applications and interpretation in PMDs.
The concept of PORT_ID is a
From: Andrew Rybchenko
Add support for items PORT_REPRESENTOR and REPRESENTED_PORT
based on the existing support for item PORT_ID.
The use of item PORT_ID depends on the specified direction attribute.
Items PORT_REPRESENTOR and REPRESENTED_PORT, in turn, define traffic
direction themselves. The
From: Andrew Rybchenko
Add support for actions PORT_REPRESENTOR and REPRESENTED_PORT
based on the existing support for action PORT_ID.
Signed-off-by: Andrew Rybchenko
---
drivers/net/enic/enic_fm_flow.c | 93 ++---
1 file changed, 75 insertions(+), 18 deletions(-)
From: Andrew Rybchenko
Semantics of the existing support for action PORT_ID suggests
that support for equal action REPRESENTED_PORT be implemented.
Helper functions keep port_id suffix since action
MLX5_FLOW_ACTION_PORT_ID is still used internally.
Signed-off-by: Andrew Rybchenko
---
doc/guid
From: Andrew Rybchenko
Action PORT_ID implementation assumes ingress only. Its semantics
suggests that support for equal action PORT_REPRESENTOR be added.
Signed-off-by: Andrew Rybchenko
---
doc/guides/nics/octeontx2.rst | 5 -
drivers/net/octeontx2/otx2_flow_parse.c | 16 ++
From: Andrew Rybchenko
Add support for item PORT_REPRESENTOR which should
be used instead of ambiguous item PORT_ID.
Signed-off-by: Andrew Rybchenko
---
doc/guides/nics/sfc_efx.rst | 2 ++
drivers/net/sfc/sfc_mae.c | 72 +
2 files changed, 74 insertions(+
From: Andrew Rybchenko
Add support for actions PORT_REPRESENTOR and REPRESENTED_PORT
based on the existing support for action PORT_ID.
Signed-off-by: Andrew Rybchenko
---
drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c | 12 ++-
drivers/net/bnxt/tf_ulp/ulp_rte_parser.c | 84 ++--
On Sat, Oct 9, 2021 at 1:20 PM Dmitry Kozlyuk wrote:
snip
> > > +Access to physical addresses is provided by a kernel-mode driver,
> > > virt2phys.
> > > +It is mandatory for allocating physically-contiguous memory which is
> > > required
> > > +by hardware PMDs.
> >
> > Should we add specific
51 matches
Mail list logo
