The new devargs format does not recognize a particular device name.
Each bus uses its specific format.
Instead of introducing a new bus API, process those devargs privately
for the moment. Prepare them for matching during scan against the
bus devices.
Signed-off-by: Gaetan Rivet
---
drivers/bus
Signed-off-by: Gaetan Rivet
---
lib/librte_ethdev/Makefile| 3 +-
lib/librte_ethdev/meson.build | 1 +
lib/librte_ethdev/rte_class_eth.c | 79 +++
3 files changed, 82 insertions(+), 1 deletion(-)
create mode 100644 lib/librte_ethdev/rte_class_eth.c
diff
The eth device class can now parse a field name,
matching the eth_dev name with one passed as
"class=eth,name=xx"
Signed-off-by: Gaetan Rivet
---
lib/librte_ethdev/rte_class_eth.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/lib/librte_ethdev/rte_class_eth.c
b/lib/librte_e
A new interactive command is offered:
show device
This commands lists all rte_device element matching the device
description. e.g.:
show device bus=pci
show device bus=vdev
show device bus=vdev/class=eth
show device bus=vdev,driver=net_ring/class=eth
show device bus=vdev/class
Introduce the facility to process future PCI parameters.
Once the matching between PCI devices and devargs has been done, it is
possible to process each devargs. New parameters would have the PCI
device handle to work with when parsing the device (bus specific)
parameters.
Signed-off-by: Gaetan R
The new devargs format does not recognize a particular device name.
Each bus uses its specific format.
Process each devargs privately prior to attempting a bus scan.
Prepare them if they are using the new devargs format.
Signed-off-by: Gaetan Rivet
---
drivers/bus/vdev/vdev.c | 10 -
Add the --dev parameter to the EAL.
This new parameter takes a generic device declaration as argument.
It uses the new devargs parsing API.
Signed-off-by: Gaetan Rivet
---
lib/librte_eal/common/eal_common_devargs.c | 4 +++
lib/librte_eal/common/eal_common_options.c | 36 +++---
Process the class-specific arguments in a devargs.
This processing takes the form of setting the proper eth_dev fields when
relevant.
Signed-off-by: Gaetan Rivet
---
lib/librte_ethdev/eth_private.h | 5 +++
lib/librte_ethdev/rte_class_eth.c | 62 +++
lib/librte_eth
> Jiayu Hu (3):
> gso: support UDP/IPv4 fragmentation
> app/testpmd: enable UDP GSO in csum engine
> gso: update documents for UDP/IPv4 GSO
Applied, thanks
18/06/2018 14:32, Thomas Monjalon:
> A constructor is usually declared with RTE_INIT* macros.
> As it is a static function, no need to declare before its definition.
> The macro is used directly in the function definition.
>
> Signed-off-by: Thomas Monjalon
Rebased after crypto pull and applied
On Wed, Jun 27, 2018 at 08:08:10PM +0200, Adrien Mazarguil wrote:
> With mlx5, unlike normal flow rules implemented through Verbs for traffic
> emitted and received by the application, those targeting different logical
> ports of the device (VF representors for instance) are offloaded at the
> swit
> -Original Message-
> From: Andrew Rybchenko [mailto:arybche...@solarflare.com]
> Sent: Thursday, July 12, 2018 12:05 AM
> To: Zhang, Qi Z ; tho...@monjalon.net; Burakov,
> Anatoly
> Cc: Ananyev, Konstantin ; dev@dpdk.org;
> Richardson, Bruce ; Yigit, Ferruh
> ; Shelton, Benjamin H
> ;
On Wed, Jun 27, 2018 at 08:08:12PM +0200, Adrien Mazarguil wrote:
> Because mlx5 switch flow rules are configured through Netlink (TC
> interface) and have little in common with Verbs, this patch adds a separate
> parser function to handle them.
>
> - mlx5_nl_flow_transpose() converts a rte_flow r
On Wed, Jun 27, 2018 at 08:08:14PM +0200, Adrien Mazarguil wrote:
> This patch enables creation of rte_flow rules that direct matching traffic
> to a different port (e.g. another VF representor) or drop it directly at
> the switch level (PORT_ID and DROP actions).
>
> Testpmd examples:
>
> - Dire
On Wed, Jun 27, 2018 at 08:08:16PM +0200, Adrien Mazarguil wrote:
> This enables flow rules to explicitly match supported combinations of
> Ethernet, IPv4, IPv6, TCP and UDP headers at the switch level.
>
> Testpmd example:
>
> - Dropping TCPv4 traffic with a specific destination on port ID 2:
>
On Wed, Jun 27, 2018 at 08:08:18PM +0200, Adrien Mazarguil wrote:
> This enables flow rules to explicitly match VLAN traffic (VLAN pattern
> item) and perform various operations on VLAN headers at the switch level
> (OF_POP_VLAN, OF_PUSH_VLAN, OF_SET_VLAN_VID and OF_SET_VLAN_PCP actions).
>
> Test
On Wed, Jun 27, 2018 at 08:08:20PM +0200, Adrien Mazarguil wrote:
> This enables flow rules to match traffic coming from a different DPDK port
> ID associated with the device (PORT_ID pattern item), mainly for the
> convenience of applications that want to deal with a single port ID for all
> flow
Add driver API rte_eth_release_port_private to support the
case when an ethdev need to be detached on a secondary process.
Local state is set to unused and shared data will not be reset
so the primary process can still use it.
Signed-off-by: Qi Zhang
Reviewed-by: Andrew Rybchenko
Acked-by: Remy
When use memcmp to compare two PCI address, sizeof(struct rte_pci_addr)
is 4 bytes aligned, and it is 8. While only 7 byte of struct rte_pci_addr
is valid. So compare the 8th byte will cause the unexpected result, which
happens when repeatedly attach/detach a device.
Fixes: c752998b5e2e ("pci: int
v13:
- Since rte_eth_dev_attach/rte_eth_dev_detach will be deprecated,
so, modify the sample code to use rte_eal_hotplug_add and
rte_eal_hotplug_remove to attach/detach device.
v12:
- fix return value in eal_dev_hotplug_request_to_primary.
- add more error log in rte_eal_hotplug_add.
- fix ret
We are going to introduce the solution to handle hotplug in
multi-process, it includes the below scenario:
1. Attach a device from the primary
2. Detach a device from the primary
3. Attach a device from a secondary
4. Detach a device from a secondary
In the primary-secondary process model, we ass
Clear vfio_group_fd is not necessary to involve any IPC.
Also, current IPC implementation for SOCKET_CLR_GROUP is not
correct. rte_vfio_clear_group on secondary will always fail,
that prevent device be detached correctly on a secondary process.
The patch simply removes all IPC related stuff in
rte_
Previously, detach port on a secondary process will mess primary
process and cause the same device can't be attached back again.
A secondary process should use rte_eth_release_port_private to
release a port.
Signed-off-by: Qi Zhang
---
drivers/net/ixgbe/ixgbe_ethdev.c | 3 +++
1 file changed, 3
Subroutine to unmap VFIO resource is shared by secondary and
primary, and it does not work on the secondary process. Since
for secondary process, it is not necessary to close interrupt
handler, set pci bus mastering and remove vfio_res from
vfio_res_list. So, the patch adds a dedicate function to h
This patch cover the multi-process hotplug case when a device
attach/detach request be issued from a secondary process
device attach on secondary:
a) secondary send sync request to the primary.
b) primary receive the request and attach the new device if
failed goto i).
c) primary forward attach
Attach port from secondary should ignore devargs since the private
device is not necessary to support. Also previously, detach port on
a secondary process will mess primary process and cause the same
device can't be attached back again. A secondary process should use
rte_eth_release_port_private to
Previously, detach port on a secondary process will mess primary
process and cause the same device can't be attached back again.
A secondary process should use rte_eth_release_port_private to
release a port.
Signed-off-by: Qi Zhang
---
drivers/net/i40e/i40e_ethdev.c | 2 ++
1 file changed, 2 ins
Attach port from secondary should ignore devargs since the private
device is not necessary to support. Also previously, detach port on
a secondary process will mess primary process and cause the same
device can't be attached back again. A secondary process should use
rte_eth_release_port_private to
Attach port from secondary should ignore devargs since the private
device is not necessary to support. Also previously, detach port on
a secondary process will mess primary process and cause the same
device can't be attached back again. A secondary process should use
rte_eth_release_port_private to
Attach port from secondary should ignore devargs since the private
device is not necessary to support. Also previously, detach port on
a secondary process will mess primary process and cause the same
device can't be attached back again. A secondary process should use
rte_eth_release_port_private to
Attach port from secondary should ignore devargs since the private
device is not necessary to support. Also previously, detach port on
a secondary process will mess primary process and cause the same
device can't be attached back again. A secondary process should use
rte_eth_release_port_private to
Attach port from secondary should ignore devargs since the private
device is not necessary to support. Also previously, detach port on
a secondary process will mess primary process and cause the same
device can't be attached back again. A secondary process should use
rte_eth_release_port_private to
Attach port from secondary should ignore devargs since the private
device is not necessary to support. Also previously, detach port on
a secondary process will mess primary process and cause the same
device can't be attached back again. A secondary process should use
rte_eth_release_port_private to
Attach port from secondary should ignore devargs since the private
device is not necessary to support. Also previously, detach port on
a secondary process will mess primary process and cause the same
device can't be attached back again. A secondary process should use
rte_eth_release_port_private to
Attach port from secondary should ignore devargs since the private
device is not necessary to support. Also previously, detach port on
a secondary process will mess primary process and cause the same
device can't be attached back again. A secondary process should use
rte_eth_release_port_private to
The sample code demonstrates device (ethdev only) management
at a multi-process environment. The user can attach/detach a
device on primary process and see it is synced on secondary
process automatically.
How to start?
./hotplug_mp --proc-type=auto
Command Line Example:
>help
>list
/* attach a
Update release notes for the new multi-process hotplug feature.
Signed-off-by: Qi Zhang
---
doc/guides/rel_notes/release_18_08.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/doc/guides/rel_notes/release_18_08.rst
b/doc/guides/rel_notes/release_18_08.rst
index bc0124295..12
v13:
- Since rte_eth_dev_attach/rte_eth_dev_detach will be deprecated,
so, modify the sample code to use rte_eal_hotplug_add and
rte_eal_hotplug_remove to attach/detach device.
v12:
- fix return value in eal_dev_hotplug_request_to_primary.
- add more error log in rte_eal_hotplug_add.
- fix ret
v13:
- Since rte_eth_dev_attach/rte_eth_dev_detach will be deprecated,
so, modify the sample code to use rte_eal_hotplug_add and
rte_eal_hotplug_remove to attach/detach device.
v12:
- fix return value in eal_dev_hotplug_request_to_primary.
- add more error log in rte_eal_hotplug_add.
- fix ret
Hi, Stephen,
You are correct and we understand that spinlock might be slightly faster than
counter based rwlock in this case. However, the counter based rwlock is the
exception path when TSX fails.
If performance of this exception path is a big concern, a more optimal
read-write lock scheme (e
Hi, Honnappa,
Thanks for the comment.
RCU can handle one of the currency issue (key deletion while lookup) that has
been discussed before, but we think it is not easy for RCU-alone to
protect reader from cuckoo path displacement. Also, RCU solution requires user
interaction.
We agree that the
> -Original Message-
> From: Guo, Jia
> Sent: Wednesday, July 11, 2018 6:42 PM
>
> When device be hotplug out, the pci resource will be released in kernel,
> the uio fd will disappear, and the irq will be released. At this time,
> if igb uio driver still try to access or release these res
Rte_fdir_conf of rte_eth_conf should be initialized before
port initialization.
Fixes: 4a3ef59a10c8 ("examples/flow_filtering: add simple demo of flow API")
Cc: sta...@dpdk.org
Signed-off-by: Rosen Xu
---
examples/flow_filtering/main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/e
Hi Yipeng,
I agree with you on RCU. It solves only part of the problem and
requires application involvement. Use of atomics is required to solve few more
problems.
Not solving the preemptible writer issue will change the behavior for existing
applications, is that ok?
I will submit a R
SPDK blobfs encountered a crash around rte_ring dequeues in ppc64.
It uses a single consumer and multiple producers for a rte_ring.
The problem was a load-load reorder in rte_ring_sc_dequeue_bulk().
The reordered loads happened on r->prod.tail in
__rte_ring_move_cons_head() (rte_ring_generic.h) an
The workaround of BAR0 mapping does not work if BAR0 area is smaller
than page size (64KB in ppc). In addition, we no longer need the
workaround in recent Linux because VFIO allows MSIX mapping (*).
This fix is just to skip the workaround if BAR0 is smarller than a page.
(*): "vfio-pci: Allow mapp
The workaround of BAR0 mapping does not work if BAR0 area is smaller
than page size (64KB in ppc). In addition, we no longer need the
workaround in recent Linux because VFIO allows MSIX mapping (*).
This fix is just to skip the workaround if BAR0 is smarller than a page.
(*): "vfio-pci: Allow mapp
On 7/11/2018 11:46 PM, Stephen Hemminger wrote:
On Wed, 11 Jul 2018 18:41:50 +0800
Jeff Guo wrote:
As we know, hot plug is an importance feature, either use for the datacenter
device’s fail-safe, or use for SRIOV Live Migration in SDN/NFV. It could bring
the higher flexibility and continual
> -Original Message-
> From: Li, Xiaoyun
> Sent: Wednesday, July 11, 2018 10:16 AM
> To: Zhang, Qi Z ; Lu, Wenzhuo
> Cc: dev@dpdk.org; Li, Xiaoyun ; sta...@dpdk.org
> Subject: [PATCH v2] app/testpmd: fix little perf drop with XL710
>
> There is about 1.8M perf drop with XL710. And it i
Hi Rosen,
Why do the fdir_conf must be initialized?
What is the issue you are seeing?
Best,
Ori
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Rosen Xu
> Sent: Thursday, July 12, 2018 5:10 AM
> To: dev@dpdk.org
> Cc: rosen...@intel.com; ferruh.yi...@intel.co
The device information cannot be gotten correctly before
the configuration is set. Because on some NICs the
information has dependence on the configuration.
Fixes: 3be82f5cc5e3 ("ethdev: support PMD-tuned Tx/Rx parameters")
Signed-off-by: Wenzhuo Lu
---
lib/librte_ethdev/rte_ethdev.c | 47 ++
Hi Ori,
examples/flow_filtering sample app fails on i40e [1] because i40e requires
explicit FDIR configuration.
But rte_flow in and hardware independent ways of describing flow-action, it
shouldn't require specific config options for specific hardware.
Is there any chance driver select the FDI
>-Original Message-
>From: De Lara Guarch, Pablo [mailto:pablo.de.lara.gua...@intel.com]
>Sent: 11 July 2018 18:56
>To: Verma, Shally
>Cc: dev@dpdk.org; Athreya, Narayana Prasad
>; Challa, Mahipal
>; Sahu, Sunila ; Sahu,
>Sunila ; Gupta, Ashish
>
>Subject: RE: [PATCH v2 4/5] compress/
Hi Stephen,
Thursday, July 12, 2018 12:08 AM, Stephen Hemminger:
> Subject: [BUG] mlx5 build failure on Debian testing
>
> I am seeing a build failure of MLX5 driver on Debian testing (buster) with
> dpdk.org master branch.
>
> This is using libibverbs-dev version 19.0-1
>
> The failure is:
> m
Hi Xiaoyun,
> -Original Message-
> From: Li, Xiaoyun
> Sent: Wednesday, July 11, 2018 10:16 AM
> To: Zhang, Qi Z ; Lu, Wenzhuo
>
> Cc: dev@dpdk.org; Li, Xiaoyun ; sta...@dpdk.org
> Subject: [PATCH v2] app/testpmd: fix little perf drop with XL710
>
> There is about 1.8M perf drop with XL
Hi,
PSB
> -Original Message-
> From: Xu, Rosen [mailto:rosen...@intel.com]
> Sent: Thursday, July 12, 2018 8:27 AM
> To: Ori Kam ; dev@dpdk.org
> Cc: Yigit, Ferruh ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] examples/flow_filtering: add rte_fdir_conf
> initialization
>
> Hi Ori,
Hi Ori,
Pls see my reply.
Hi Walter and Ferruh,
I need your voice :)
> -Original Message-
> From: Ori Kam [mailto:or...@mellanox.com]
> Sent: Thursday, July 12, 2018 13:58
> To: Xu, Rosen ; dev@dpdk.org
> Cc: Yigit, Ferruh ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] examples/flo
On Thursday 12 July 2018 03:14 AM, Gaetan Rivet wrote:
This abstraction exists since the infancy of DPDK.
It needs to be fleshed out however, to allow a generic
description of devices properties and capabilities.
A device class is the northbound interface of the device, intended
for applications
The flow counter support introduced by
commit 9a761de8ea14 ("net/mlx5: flow counter support") was intend to
work only with MLNX_OFED_4.3 as the upstream rdma-core
libraries were lack such support.
On rdma-core v19 the support for the flow counters was added but with
different user APIs, hence caus
201 - 259 of 259 matches
Mail list logo
