* [PATCH] eal: fix libabi macro for device generalization patches
From: Shreyansh Jain @ 2016-10-26 12:38 UTC (permalink / raw)
To: thomas.monjalon; +Cc: dev, Shreyansh Jain
rte_device/driver generalization patches [1] were merged without a change
in the LIBABIVER macro. This patches bumps the macro of affected libs.
Also, deprecation notice from 16.07 has been removed and release notes for
16.11 added.
[1] http://dpdk.org/ml/archives/dev/2016-September/047087.html
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
---
doc/guides/rel_notes/deprecation.rst | 12 ------------
doc/guides/rel_notes/release_16_11.rst | 16 ++++++++++++++++
lib/librte_cryptodev/Makefile | 2 +-
lib/librte_eal/bsdapp/eal/Makefile | 2 +-
lib/librte_eal/linuxapp/eal/Makefile | 2 +-
lib/librte_ether/Makefile | 2 +-
6 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index d5c1490..884a231 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -18,18 +18,6 @@ Deprecation Notices
``nb_seg_max`` and ``nb_mtu_seg_max`` providing information about number of
segments limit to be transmitted by device for TSO/non-TSO packets.
-* The ethdev hotplug API is going to be moved to EAL with a notification
- mechanism added to crypto and ethdev libraries so that hotplug is now
- available to both of them. This API will be stripped of the device arguments
- so that it only cares about hotplugging.
-
-* Structures embodying pci and vdev devices are going to be reworked to
- integrate new common rte_device / rte_driver objects (see
- http://dpdk.org/ml/archives/dev/2016-January/031390.html).
- ethdev and crypto libraries will then only handle those objects so that they
- do not need to care about the kind of devices that are being used, making it
- easier to add new buses later.
-
* ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: some fields
may be reordered to facilitate the writing of ``data_off``, ``refcnt``, and
``nb_segs`` in one operation, because some platforms have an overhead if the
diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
index 26cdd62..c3f3bd9 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -149,6 +149,22 @@ Resolved Issues
EAL
~~~
+* **Improved device/driver heirarchy and generalized hotplugging**
+
+ Device and driver relationship has been restructured by introducing generic
+ classes. This paves way for having PCI, VDEV and other device types as
+ just instantiated objects rather than classes in themselves. Hotplugging too
+ has been generalized into EAL so that ethernet or cryptodevices can use the
+ common infrastructure.
+
+ * removed pmd_type as way of segragation of devices
+ * added rte_device class and all PCI and VDEV devices inherit from it
+ * renamed devinit/devuninit handlers to probe/remove to make it more
+ semantically correct with respect to device<=>driver relationship
+ * moved hotplugging support to EAL
+ * helpers and support macros have been renamed to make them more synonymous
+ with their device types (e.g. PMD_REGISTER_DRIVER => DRIVER_REGISTER_PCI)
+
Drivers
~~~~~~~
diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cryptodev/Makefile
index 314a046..aebf5d9 100644
--- a/lib/librte_cryptodev/Makefile
+++ b/lib/librte_cryptodev/Makefile
@@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_cryptodev.a
# library version
-LIBABIVER := 1
+LIBABIVER := 2
# build flags
CFLAGS += -O3
diff --git a/lib/librte_eal/bsdapp/eal/Makefile b/lib/librte_eal/bsdapp/eal/Makefile
index a15b762..122798c 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -48,7 +48,7 @@ LDLIBS += -lgcc_s
EXPORT_MAP := rte_eal_version.map
-LIBABIVER := 3
+LIBABIVER := 4
# specific to bsdapp exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
diff --git a/lib/librte_eal/linuxapp/eal/Makefile b/lib/librte_eal/linuxapp/eal/Makefile
index 4e206f0..4ad7c85 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -37,7 +37,7 @@ ARCH_DIR ?= $(RTE_ARCH)
EXPORT_MAP := rte_eal_version.map
VPATH += $(RTE_SDK)/lib/librte_eal/common/arch/$(ARCH_DIR)
-LIBABIVER := 3
+LIBABIVER := 4
VPATH += $(RTE_SDK)/lib/librte_eal/common
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index 488b7c8..bc2e5f6 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)
EXPORT_MAP := rte_ether_version.map
-LIBABIVER := 4
+LIBABIVER := 5
SRCS-y += rte_ethdev.c
--
2.7.4
^ permalink raw reply related
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-10-26 12:24 UTC (permalink / raw)
To: Van Haaren, Harry
Cc: Vangati, Narender, dev@dpdk.org, Eads, Gage,
thomas.monjalon@6wind.com
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA6129AD56F@IRSMSX102.ger.corp.intel.com>
On Wed, Oct 26, 2016 at 12:11:03PM +0000, Van Haaren, Harry wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> >
> > So far, I have received constructive feedback from Intel, NXP and Linaro folks.
> > Let me know, if anyone else interested in contributing to the definition of eventdev?
> >
> > If there are no major issues in proposed spec, then Cavium would like work on
> > implementing and up-streaming the common code(lib/librte_eventdev/) and
> > an associated HW driver.(Requested minor changes of v2 will be addressed
> > in next version).
>
> Hi All,
>
> I will propose a minor change to the rte_event struct, allowing some bits to be implementation specific. Currently the rte_event struct has no space to allow an implementation store any metadata about the event. For software performance it would be really helpful if there are some bits available for the implementation to keep some flags about each event.
OK.
>
> I suggest to rework the struct as below which opens 6 bits that were otherwise wasted, and define them as implementation specific. By implementation specific it is understood that the implementation can overwrite any information stored in those bits, and the application must not expect the data to remain after the event is scheduled.
>
> OLD:
> struct rte_event {
> uint32_t flow_id:24;
> uint32_t queue_id:8;
> uint8_t sched_type; /* Note only 2 bits of 8 are required */
>
> NEW:
> struct rte_event {
> uint32_t flow_id:24;
> uint32_t sched_type:2; /* reduced size : but 2 bits is enough for the enqueue types Ordered,Atomic,Parallel.*/
> uint32_t implementation:6; /* available for implementation specific metadata */
> uint8_t queue_id; /* still 8 bits as before */
>
>
> Thoughts? -Harry
Looks good to me. I will add it in v3.
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Van Haaren, Harry @ 2016-10-26 12:11 UTC (permalink / raw)
To: Jerin Jacob, dev@dpdk.org
Cc: Vangati, Narender, thomas.monjalon@6wind.com, Eads, Gage
In-Reply-To: <20161025174904.GA18333@localhost.localdomain>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
>
> So far, I have received constructive feedback from Intel, NXP and Linaro folks.
> Let me know, if anyone else interested in contributing to the definition of eventdev?
>
> If there are no major issues in proposed spec, then Cavium would like work on
> implementing and up-streaming the common code(lib/librte_eventdev/) and
> an associated HW driver.(Requested minor changes of v2 will be addressed
> in next version).
Hi All,
I will propose a minor change to the rte_event struct, allowing some bits to be implementation specific. Currently the rte_event struct has no space to allow an implementation store any metadata about the event. For software performance it would be really helpful if there are some bits available for the implementation to keep some flags about each event.
I suggest to rework the struct as below which opens 6 bits that were otherwise wasted, and define them as implementation specific. By implementation specific it is understood that the implementation can overwrite any information stored in those bits, and the application must not expect the data to remain after the event is scheduled.
OLD:
struct rte_event {
uint32_t flow_id:24;
uint32_t queue_id:8;
uint8_t sched_type; /* Note only 2 bits of 8 are required */
NEW:
struct rte_event {
uint32_t flow_id:24;
uint32_t sched_type:2; /* reduced size : but 2 bits is enough for the enqueue types Ordered,Atomic,Parallel.*/
uint32_t implementation:6; /* available for implementation specific metadata */
uint8_t queue_id; /* still 8 bits as before */
Thoughts? -Harry
^ permalink raw reply
* Re: [PATCH] pdump: revert PCI device name conversion
From: Zhang, Roy Fan @ 2016-10-26 11:22 UTC (permalink / raw)
To: Pattan, Reshma, dev@dpdk.org
In-Reply-To: <1477413098-3121-1-git-send-email-reshma.pattan@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Reshma Pattan
> Sent: Tuesday, October 25, 2016 5:32 PM
> To: dev@dpdk.org
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [dpdk-dev] [PATCH] pdump: revert PCI device name conversion
>
> Earlier ethdev library created the device names in the "bus:device.func"
> format hence pdump library implemented its own conversion method for
> changing the user passed device name format "domain:bus:device.func" to
> "bus:device.func"
> for finding the port id using device name using ethdev library calls. Now after
> ethdev and eal rework http://dpdk.org/dev/patchwork/patch/15855/,
> the device names are created in the format "domain:bus:device.func", so
> pdump library conversion is not needed any more, hence removed the
> corresponding code.
>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> ---
> lib/librte_pdump/rte_pdump.c | 37 ++-----------------------------------
> 1 file changed, 2 insertions(+), 35 deletions(-)
>
> diff --git a/lib/librte_pdump/rte_pdump.c b/lib/librte_pdump/rte_pdump.c
> index ea5ccd9..504a1ce 100644
> --- a/lib/librte_pdump/rte_pdump.c
> +++ b/lib/librte_pdump/rte_pdump.c
> @@ -226,29 +226,6 @@ pdump_tx(uint8_t port __rte_unused, uint16_t qidx
> __rte_unused, }
>
> static int
> -pdump_get_dombdf(char *device_id, char *domBDF, size_t len) -{
> - int ret;
> - struct rte_pci_addr dev_addr = {0};
> -
> - /* identify if device_id is pci address or name */
> - ret = eal_parse_pci_DomBDF(device_id, &dev_addr);
> - if (ret < 0)
> - return -1;
> -
> - if (dev_addr.domain)
> - ret = snprintf(domBDF, len, "%u:%u:%u.%u",
> dev_addr.domain,
> - dev_addr.bus, dev_addr.devid,
> - dev_addr.function);
> - else
> - ret = snprintf(domBDF, len, "%u:%u.%u", dev_addr.bus,
> - dev_addr.devid,
> - dev_addr.function);
> -
> - return ret;
> -}
> -
> -static int
> pdump_regitser_rx_callbacks(uint16_t end_q, uint8_t port, uint16_t queue,
> struct rte_ring *ring, struct rte_mempool
> *mp,
> uint16_t operation)
> @@ -885,7 +862,6 @@ rte_pdump_enable_by_deviceid(char *device_id,
> uint16_t queue,
> void *filter)
> {
> int ret = 0;
> - char domBDF[DEVICE_ID_SIZE];
>
> ret = pdump_validate_ring_mp(ring, mp);
> if (ret < 0)
> @@ -894,11 +870,7 @@ rte_pdump_enable_by_deviceid(char *device_id,
> uint16_t queue,
> if (ret < 0)
> return ret;
>
> - if (pdump_get_dombdf(device_id, domBDF, sizeof(domBDF)) > 0)
> - ret = pdump_prepare_client_request(domBDF, queue, flags,
> - ENABLE, ring, mp, filter);
> - else
> - ret = pdump_prepare_client_request(device_id, queue,
> flags,
> + ret = pdump_prepare_client_request(device_id, queue, flags,
> ENABLE, ring, mp, filter);
>
> return ret;
> @@ -928,17 +900,12 @@ rte_pdump_disable_by_deviceid(char *device_id,
> uint16_t queue,
> uint32_t flags)
> {
> int ret = 0;
> - char domBDF[DEVICE_ID_SIZE];
>
> ret = pdump_validate_flags(flags);
> if (ret < 0)
> return ret;
>
> - if (pdump_get_dombdf(device_id, domBDF, sizeof(domBDF)) > 0)
> - ret = pdump_prepare_client_request(domBDF, queue, flags,
> - DISABLE, NULL, NULL, NULL);
> - else
> - ret = pdump_prepare_client_request(device_id, queue,
> flags,
> + ret = pdump_prepare_client_request(device_id, queue, flags,
> DISABLE, NULL, NULL, NULL);
>
> return ret;
> --
> 2.7.4
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
^ permalink raw reply
* [dpdk-announce] DPDK 16.07.1 released
From: Yuanhan Liu @ 2016-10-26 11:17 UTC (permalink / raw)
To: announce; +Cc: dpdk stable
Hi all,
Please join me in announcing the first DPDK stable release:
http://fast.dpdk.org/rel/dpdk-16.07.1.tar.xz
It includes most bug fixing patches before v16.11-rc1. Few
are missed in this release window and will be carried in
the next stable release.
Thanks.
--yliu
---
app/test-pmd/cmdline.c | 2 +-
app/test-pmd/testpmd.c | 10 +-
app/test/test_cryptodev.c | 14 +--
buildtools/pmdinfogen/pmdinfogen.c | 2 +-
doc/guides/rel_notes/release_16_07.rst | 50 +++++++++
drivers/crypto/kasumi/rte_kasumi_pmd.c | 8 +-
drivers/crypto/null/null_crypto_pmd_ops.c | 2 +-
drivers/crypto/qat/qat_adf/icp_qat_fw.h | 2 +-
drivers/crypto/snow3g/rte_snow3g_pmd.c | 8 +-
drivers/net/e1000/igb_rxtx.c | 2 +-
drivers/net/enic/base/vnic_dev.c | 36 ++++---
drivers/net/enic/enic_rxtx.c | 5 +-
drivers/net/fm10k/fm10k_ethdev.c | 5 +
drivers/net/i40e/base/i40e_common.c | 2 +-
drivers/net/i40e/i40e_ethdev.c | 37 ++++---
drivers/net/i40e/i40e_rxtx.c | 15 ++-
drivers/net/i40e/i40e_rxtx_vec.c | 16 ++-
drivers/net/ixgbe/base/ixgbe_common.c | 113 ++++++++++++---------
drivers/net/ixgbe/base/ixgbe_common.h | 1 +
drivers/net/ixgbe/base/ixgbe_vf.c | 13 +--
drivers/net/ixgbe/base/ixgbe_x550.c | 57 +++--------
drivers/net/ixgbe/base/ixgbe_x550.h | 2 -
drivers/net/ixgbe/ixgbe_ethdev.c | 12 ++-
drivers/net/ixgbe/ixgbe_rxtx_vec_common.h | 16 ++-
drivers/net/mlx4/mlx4.c | 8 +-
drivers/net/mlx5/mlx5.c | 8 +-
drivers/net/mlx5/mlx5.h | 8 +-
drivers/net/mlx5/mlx5_ethdev.c | 4 +-
drivers/net/mlx5/mlx5_fdir.c | 8 +-
drivers/net/mlx5/mlx5_mac.c | 8 +-
drivers/net/mlx5/mlx5_mr.c | 8 +-
drivers/net/mlx5/mlx5_prm.h | 4 +-
drivers/net/mlx5/mlx5_rss.c | 8 +-
drivers/net/mlx5/mlx5_rxmode.c | 8 +-
drivers/net/mlx5/mlx5_rxq.c | 8 +-
drivers/net/mlx5/mlx5_rxtx.c | 8 +-
drivers/net/mlx5/mlx5_rxtx.h | 8 +-
drivers/net/mlx5/mlx5_stats.c | 4 +-
drivers/net/mlx5/mlx5_trigger.c | 4 +-
drivers/net/mlx5/mlx5_txq.c | 8 +-
drivers/net/mlx5/mlx5_vlan.c | 4 +-
drivers/net/nfp/nfp_net.c | 4 +-
drivers/net/pcap/rte_eth_pcap.c | 4 +-
drivers/net/virtio/virtio_ethdev.c | 8 +-
drivers/net/virtio/virtio_user/virtio_user_dev.c | 112 ++++++++++++--------
drivers/net/virtio/virtio_user_ethdev.c | 42 +++++---
examples/ip_pipeline/config/diagram-generator.py | 2 +-
.../ip_pipeline/config/pipeline-to-core-mapping.py | 2 +-
examples/ip_pipeline/cpu_core_map.c | 8 ++
lib/librte_eal/bsdapp/contigmem/contigmem.c | 8 +-
lib/librte_eal/common/eal_common_pci.c | 1 +
lib/librte_eal/common/include/rte_version.h | 2 +-
lib/librte_eal/linuxapp/eal/eal_memory.c | 13 +--
lib/librte_hash/rte_cuckoo_hash.c | 12 ++-
lib/librte_mbuf/rte_mbuf.c | 8 +-
lib/librte_mempool/rte_mempool.c | 2 +-
lib/librte_sched/rte_sched.c | 18 ++--
lib/librte_table/rte_table_version.map | 3 +
lib/librte_timer/rte_timer.c | 2 +-
pkg/dpdk.spec | 2 +-
tools/dpdk-devbind.py | 11 +-
tools/dpdk-pmdinfo.py | 2 +-
62 files changed, 495 insertions(+), 317 deletions(-)
Alejandro Lucero (1):
net/nfp: fix copying MAC address
Aleksey Katargin (1):
table: fix symbol exports
Alex Zelezniak (1):
net/ixgbe: fix VF reset to apply to correct VF
Ali Volkan Atli (1):
net/e1000: fix returned number of available Rx descriptors
Arek Kusztal (1):
app/test: fix verification of digest for GCM
Beilei Xing (2):
net/i40e: fix dropping packets with ethertype 0x88A8
net/i40e: fix parsing QinQ packets type
Bruce Richardson (1):
net/mlx: fix debug build with gcc 6.1
Christian Ehrhardt (1):
examples/ip_pipeline: fix Python interpreter
Deepak Kumar Jain (2):
crypto/null: fix key size increment value
crypto/qat: fix FreeBSD build
Dror Birkman (1):
net/pcap: fix memory leak in jumbo frames
Ferruh Yigit (2):
app/testpmd: fix help of MTU set commmand
pmdinfogen: fix clang build
Gary Mussar (1):
tools: fix virtio interface name when binding
Gowrishankar Muthukrishnan (1):
examples/ip_pipeline: fix lcore mapping for ppc64
Hiroyuki Mikita (1):
sched: fix releasing enqueued packets
James Poole (1):
app/testpmd: fix timeout in Rx queue flushing
Jianfeng Tan (3):
net/virtio_user: fix first queue pair without multiqueue
net/virtio_user: fix wrong sequence of messages
net/virtio_user: fix error management during init
Jim Harris (1):
contigmem: zero all pages during mmap
John Daley (1):
net/enic: fix bad L4 checksum flag on ICMP packets
Karmarkar Suyash (1):
timer: fix lag delay
Maciej Czekaj (1):
mem: fix crash on hugepage mapping error
Nelson Escobar (1):
net/enic: fix freeing memory for descriptor ring
Olivier Matz (4):
app/testpmd: fix crash when mempool allocation fails
tools: fix json output of pmdinfo
mbuf: fix error handling on pool creation
mem: fix build with -O1
Pablo de Lara (3):
hash: fix ring size
hash: fix false zero signature key hit lookup
crypto: fix build with icc
Qi Zhang (1):
net/i40e/base: fix UDP packet header
Rich Lane (1):
net/i40e: fix null pointer dereferences when using VMDq+RSS
Weiliang Luo (1):
mempool: fix corruption due to invalid handler
Xiao Wang (5):
net/fm10k: fix MAC address removal from switch
net/ixgbe/base: fix pointer check
net/ixgbe/base: fix check for NACK
net/ixgbe/base: fix possible corruption of shadow RAM
net/ixgbe/base: fix skipping PHY config
Yangchao Zhou (1):
pci: fix memory leak when detaching device
Yuanhan Liu (1):
version: 16.07.1
Yury Kylulin (2):
net/ixgbe: fix mbuf leak during Rx queue release
net/i40e: fix mbuf leak during Rx queue release
Zhiyong Yang (1):
net/virtio: fix xstats name
^ permalink raw reply
* [PATCH v2] release 16.07.1
From: Thomas Monjalon @ 2016-10-26 9:46 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev
In-Reply-To: <1477469498-19637-1-git-send-email-yuanhan.liu@linux.intel.com>
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
A quick download button is added for the latest stable release.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
v2:
- buttons on one row
- md5 of tarball
---
content.css | 4 ++--
download.html | 10 +++++++---
rel.html | 6 +++---
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/content.css b/content.css
index 4bd7240..4b469bd 100644
--- a/content.css
+++ b/content.css
@@ -105,11 +105,11 @@ section .button:hover {
}
section#download .button,
section#rel .button {
- width: 26%;
+ width: 18%;
}
section#download .button + .button,
section#rel .button + .button {
- margin-left: 11%;
+ margin-left: 9.3%;
}
section#events .button {
padding: 1em 3em;
diff --git a/download.html b/download.html
index 919c41e..dc5c802 100644
--- a/download.html
+++ b/download.html
@@ -41,15 +41,19 @@
<h2>Download</h2>
<a href="http://fast.dpdk.org/rel/dpdk-16.07.tar.xz" class="button">
<i class="material-icons">archive</i>
- Latest Version: 16.07
+ Latest Major<br>16.07
+ </a><!-- no whitespace
+ --><a href="http://fast.dpdk.org/rel/dpdk-16.07.1.tar.xz" class="button">
+ <i class="material-icons">archive</i>
+ Latest Stable<br>16.07.1
</a><!-- no whitespace
--><a href="/rel" class="button">
<i class="material-icons">view_list</i>
- Other Versions
+ <br>Other Versions
</a><!-- no whitespace
--><a href="/doc/quick-start" class="button">
<i class="material-icons">access_time</i>
- Quick Start Instructions
+ <br>Quick Start
</a>
<ul>
<h3>Applications</h3>
diff --git a/rel.html b/rel.html
index b95403a..ffdc513 100644
--- a/rel.html
+++ b/rel.html
@@ -59,9 +59,9 @@
<th>md5</th>
</tr>
<tr>
- <td><a href="http://fast.dpdk.org/rel/dpdk-16.07.tar.xz">DPDK 16.07</a></td>
- <td><a href="/doc/guides/rel_notes/release_16_07.html">2016 July 28</a></td>
- <td><pre>690a2bb570103e58d12f9806e8bf21be</pre></td>
+ <td><a href="http://fast.dpdk.org/rel/dpdk-16.07.1.tar.xz">DPDK 16.07.1</a></td>
+ <td><a href="/doc/guides/rel_notes/release_16_07.html">2016 October 26</a></td>
+ <td><pre>28b3831cebfa94ca533418c17de25986</pre></td>
</tr>
<tr>
<td><a href="http://fast.dpdk.org/rel/dpdk-16.04.tar.xz">DPDK 16.04</a></td>
--
2.7.0
^ permalink raw reply related
* [PATCH 0/2] mlx5: fix link speed capabilities
From: Nelio Laranjeiro @ 2016-10-26 9:44 UTC (permalink / raw)
To: dev
Make hard-coded values dynamic to return correct link speed capabilities
(not all ConnectX-4 NICs support everything).
Nelio Laranjeiro (2):
net/mlx5: fix link speed capability information
net/mlx5: fix support for newer link speeds
drivers/net/mlx5/Makefile | 15 +++++
drivers/net/mlx5/mlx5.h | 1 +
drivers/net/mlx5/mlx5_ethdev.c | 148 +++++++++++++++++++++++++++++++++++++----
3 files changed, 151 insertions(+), 13 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 2/2] net/mlx5: fix support for newer link speeds
From: Nelio Laranjeiro @ 2016-10-26 9:44 UTC (permalink / raw)
To: dev
In-Reply-To: <cover.1477409933.git.nelio.laranjeiro@6wind.com>
Not all speed capabilities can be reported properly before Linux 4.8 (25G,
50G and 100G speeds are missing), moreover the API to retrieve them only
exists since Linux 4.5, this commit thus implements compatibility code for
all versions.
Fixes: e274f5732225 ("ethdev: add speed capabilities")
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
drivers/net/mlx5/Makefile | 15 +++++
drivers/net/mlx5/mlx5_ethdev.c | 123 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 135 insertions(+), 3 deletions(-)
diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index 2c13c30..cf87f0b 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -121,6 +121,21 @@ mlx5_autoconf.h.new: $(RTE_SDK)/scripts/auto-config-h.sh
infiniband/mlx5_hw.h \
enum MLX5_OPCODE_TSO \
$(AUTOCONF_OUTPUT)
+ $Q sh -- '$<' '$@' \
+ HAVE_ETHTOOL_LINK_MODE_25G \
+ /usr/include/linux/ethtool.h \
+ enum ETHTOOL_LINK_MODE_25000baseCR_Full_BIT \
+ $(AUTOCONF_OUTPUT)
+ $Q sh -- '$<' '$@' \
+ HAVE_ETHTOOL_LINK_MODE_50G \
+ /usr/include/linux/ethtool.h \
+ enum ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT \
+ $(AUTOCONF_OUTPUT)
+ $Q sh -- '$<' '$@' \
+ HAVE_ETHTOOL_LINK_MODE_100G \
+ /usr/include/linux/ethtool.h \
+ enum ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT \
+ $(AUTOCONF_OUTPUT)
# Create mlx5_autoconf.h or update it in case it differs from the new one.
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 042c9bc..2d49f86 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -627,15 +627,15 @@ mlx5_dev_supported_ptypes_get(struct rte_eth_dev *dev)
}
/**
- * DPDK callback to retrieve physical link information (unlocked version).
+ * Retrieve physical link information (unlocked version using legacy ioctl).
*
* @param dev
* Pointer to Ethernet device structure.
* @param wait_to_complete
* Wait for request completion (ignored).
*/
-int
-mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
+static int
+mlx5_link_update_unlocked_gset(struct rte_eth_dev *dev, int wait_to_complete)
{
struct priv *priv = mlx5_get_priv(dev);
struct ethtool_cmd edata = {
@@ -691,6 +691,123 @@ mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
}
/**
+ * Retrieve physical link information (unlocked version using new ioctl from
+ * Linux 4.5).
+ *
+ * @param dev
+ * Pointer to Ethernet device structure.
+ * @param wait_to_complete
+ * Wait for request completion (ignored).
+ */
+static int
+mlx5_link_update_unlocked_gs(struct rte_eth_dev *dev, int wait_to_complete)
+{
+#ifdef ETHTOOL_GLINKSETTINGS
+ struct priv *priv = mlx5_get_priv(dev);
+ struct ethtool_link_settings edata = {
+ .cmd = ETHTOOL_GLINKSETTINGS,
+ };
+ struct ifreq ifr;
+ struct rte_eth_link dev_link;
+ uint64_t sc;
+
+ (void)wait_to_complete;
+ if (priv_ifreq(priv, SIOCGIFFLAGS, &ifr)) {
+ WARN("ioctl(SIOCGIFFLAGS) failed: %s", strerror(errno));
+ return -1;
+ }
+ memset(&dev_link, 0, sizeof(dev_link));
+ dev_link.link_status = ((ifr.ifr_flags & IFF_UP) &&
+ (ifr.ifr_flags & IFF_RUNNING));
+ ifr.ifr_data = (void *)&edata;
+ if (priv_ifreq(priv, SIOCETHTOOL, &ifr)) {
+ DEBUG("ioctl(SIOCETHTOOL, ETHTOOL_GLINKSETTINGS) failed: %s",
+ strerror(errno));
+ return -1;
+ }
+ dev_link.link_speed = edata.speed;
+ sc = edata.link_mode_masks[0] |
+ ((uint64_t)edata.link_mode_masks[1] << 32);
+ priv->link_speed_capa = 0;
+ /* Link speeds available in kernel v4.5. */
+ if (sc & ETHTOOL_LINK_MODE_Autoneg_BIT)
+ priv->link_speed_capa |= ETH_LINK_SPEED_AUTONEG;
+ if (sc & (ETHTOOL_LINK_MODE_1000baseT_Full_BIT |
+ ETHTOOL_LINK_MODE_1000baseKX_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_1G;
+ if (sc & (ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT |
+ ETHTOOL_LINK_MODE_10000baseKR_Full_BIT |
+ ETHTOOL_LINK_MODE_10000baseR_FEC_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_10G;
+ if (sc & (ETHTOOL_LINK_MODE_20000baseMLD2_Full_BIT |
+ ETHTOOL_LINK_MODE_20000baseKR2_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_20G;
+ if (sc & (ETHTOOL_LINK_MODE_40000baseKR4_Full_BIT |
+ ETHTOOL_LINK_MODE_40000baseCR4_Full_BIT |
+ ETHTOOL_LINK_MODE_40000baseSR4_Full_BIT |
+ ETHTOOL_LINK_MODE_40000baseLR4_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_40G;
+ if (sc & (ETHTOOL_LINK_MODE_56000baseKR4_Full_BIT |
+ ETHTOOL_LINK_MODE_56000baseCR4_Full_BIT |
+ ETHTOOL_LINK_MODE_56000baseSR4_Full_BIT |
+ ETHTOOL_LINK_MODE_56000baseLR4_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_56G;
+ /* Link speeds available in kernel v4.6. */
+#ifdef HAVE_ETHTOOL_LINK_MODE_25G
+ if (sc & (ETHTOOL_LINK_MODE_25000baseCR_Full_BIT |
+ ETHTOOL_LINK_MODE_25000baseKR_Full_BIT |
+ ETHTOOL_LINK_MODE_25000baseSR_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_25G;
+#endif
+#ifdef HAVE_ETHTOOL_LINK_MODE_50G
+ if (sc & (ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT |
+ ETHTOOL_LINK_MODE_50000baseKR2_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_50G;
+#endif
+#ifdef HAVE_ETHTOOL_LINK_MODE_100G
+ if (sc & (ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT |
+ ETHTOOL_LINK_MODE_100000baseSR4_Full_BIT |
+ ETHTOOL_LINK_MODE_100000baseCR4_Full_BIT |
+ ETHTOOL_LINK_MODE_100000baseLR4_ER4_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_100G;
+#endif
+ dev_link.link_duplex = ((edata.duplex == DUPLEX_HALF) ?
+ ETH_LINK_HALF_DUPLEX : ETH_LINK_FULL_DUPLEX);
+ dev_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
+ ETH_LINK_SPEED_FIXED);
+ if (memcmp(&dev_link, &dev->data->dev_link, sizeof(dev_link))) {
+ /* Link status changed. */
+ dev->data->dev_link = dev_link;
+ return 0;
+ }
+#else
+ (void)dev;
+ (void)wait_to_complete;
+#endif
+ /* Link status is still the same. */
+ return -1;
+}
+
+/**
+ * DPDK callback to retrieve physical link information (unlocked version).
+ *
+ * @param dev
+ * Pointer to Ethernet device structure.
+ * @param wait_to_complete
+ * Wait for request completion (ignored).
+ */
+int
+mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
+{
+ int ret;
+
+ ret = mlx5_link_update_unlocked_gs(dev, wait_to_complete);
+ if (ret < 0)
+ ret = mlx5_link_update_unlocked_gset(dev, wait_to_complete);
+ return ret;
+}
+
+/**
* DPDK callback to retrieve physical link information.
*
* @param dev
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] net/mlx5: fix link speed capability information
From: Nelio Laranjeiro @ 2016-10-26 9:44 UTC (permalink / raw)
To: dev
In-Reply-To: <cover.1477409933.git.nelio.laranjeiro@6wind.com>
Make hard-coded values dynamic to return correct link speed capabilities
(not all ConnectX-4 NICs support everything).
Fixes: e274f5732225 ("ethdev: add speed capabilities")
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
drivers/net/mlx5/mlx5.h | 1 +
drivers/net/mlx5/mlx5_ethdev.c | 25 +++++++++++++++----------
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 000fb38..d7976cb 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -139,6 +139,7 @@ struct priv {
unsigned int reta_idx_n; /* RETA index size. */
struct fdir_filter_list *fdir_filter_list; /* Flow director rules. */
struct fdir_queue *fdir_drop_queue; /* Flow director drop queue. */
+ uint32_t link_speed_capa; /* Link speed capabilities. */
rte_spinlock_t lock; /* Lock for control functions. */
};
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index b8b3ea9..042c9bc 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -604,15 +604,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
info->hash_key_size = ((*priv->rss_conf) ?
(*priv->rss_conf)[0]->rss_key_len :
0);
- info->speed_capa =
- ETH_LINK_SPEED_1G |
- ETH_LINK_SPEED_10G |
- ETH_LINK_SPEED_20G |
- ETH_LINK_SPEED_25G |
- ETH_LINK_SPEED_40G |
- ETH_LINK_SPEED_50G |
- ETH_LINK_SPEED_56G |
- ETH_LINK_SPEED_100G;
+ info->speed_capa = priv->link_speed_capa;
priv_unlock(priv);
}
@@ -647,7 +639,7 @@ mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
{
struct priv *priv = mlx5_get_priv(dev);
struct ethtool_cmd edata = {
- .cmd = ETHTOOL_GSET
+ .cmd = ETHTOOL_GSET /* Deprecated since Linux v4.5. */
};
struct ifreq ifr;
struct rte_eth_link dev_link;
@@ -672,6 +664,19 @@ mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
dev_link.link_speed = 0;
else
dev_link.link_speed = link_speed;
+ priv->link_speed_capa = 0;
+ if (edata.supported & SUPPORTED_Autoneg)
+ priv->link_speed_capa |= ETH_LINK_SPEED_AUTONEG;
+ if (edata.supported & (SUPPORTED_1000baseT_Full |
+ SUPPORTED_1000baseKX_Full))
+ priv->link_speed_capa |= ETH_LINK_SPEED_1G;
+ if (edata.supported & SUPPORTED_10000baseKR_Full)
+ priv->link_speed_capa |= ETH_LINK_SPEED_10G;
+ if (edata.supported & (SUPPORTED_40000baseKR4_Full |
+ SUPPORTED_40000baseCR4_Full |
+ SUPPORTED_40000baseSR4_Full |
+ SUPPORTED_40000baseLR4_Full))
+ priv->link_speed_capa |= ETH_LINK_SPEED_40G;
dev_link.link_duplex = ((edata.duplex == DUPLEX_HALF) ?
ETH_LINK_HALF_DUPLEX : ETH_LINK_FULL_DUPLEX);
dev_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
--
2.1.4
^ permalink raw reply related
* Re: DPDK & ASLR
From: Mcnamara, John @ 2016-10-26 9:13 UTC (permalink / raw)
To: Jon DeVree, dev@dpdk.org
In-Reply-To: <20161026042009.ktsazbm3qf6kbxdr@feynman.vault24.org>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jon DeVree
> Sent: Wednesday, October 26, 2016 5:20 AM
> To: dev@dpdk.org
> Subject: Re: [dpdk-dev] DPDK & ASLR
>
> On Tue, Oct 25, 2016 at 15:18:03 -0700, Samir Shah wrote:
> > Does ASLR need to be turned off system-wide, or DPDK-processes wide?
> > Could we use setarch/personality to disable ASLR for just the DPDK
> > process and leave it enabled for the rest of the system? Any
> > experience to say if that would work or not?
> >
>
> I'm using setarch/personality to disable it only in the processes using
> dpdk without any trouble.
Hi Jon,
That is interesting. Do you have some more details on how to do this.
Also, It might be worth adding this to the DPDK documentation:
http://dpdk.org/doc/guides/prog_guide/multi_proc_support.html#multi-process-limitations
John
^ permalink raw reply
* Re: [PATCH v10 11/25] eal/pci: helpers for device name parsing/update
From: Pattan, Reshma @ 2016-10-26 9:12 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: dev@dpdk.org, Thomas Monjalon, viktorin@rehivetech.com
In-Reply-To: <39622c65-4cbd-4841-541f-8673e1935036@nxp.com>
Hi,
> -----Original Message-----
> From: Shreyansh Jain [mailto:shreyansh.jain@nxp.com]
> Sent: Wednesday, October 26, 2016 7:23 AM
> To: Pattan, Reshma <reshma.pattan@intel.com>
> Cc: dev@dpdk.org; viktorin@rehivetech.com; David Marchand
> <david.marchand@6wind.com>; hemant.agrawal@nxp.com; Thomas Monjalon
> <thomas.monjalon@6wind.com>
> Subject: Re: [PATCH v10 11/25] eal/pci: helpers for device name parsing/update
>
> Hello Reshma,
>
> On Tuesday 25 October 2016 09:19 PM, Pattan, Reshma wrote:
> > Hi Shreyansh,
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Shreyansh Jain
> >> Sent: Friday, September 16, 2016 5:30 AM
> >> To: dev@dpdk.org
> >> Cc: viktorin@rehivetech.com; David Marchand
> >> <david.marchand@6wind.com>; hemant.agrawal@nxp.com; Thomas
> Monjalon
> >> <thomas.monjalon@6wind.com>; Shreyansh Jain <shreyansh.jain@nxp.com>
> >> Subject: [dpdk-dev] [PATCH v10 11/25] eal/pci: helpers for device
> >> name parsing/update
> >>
> >> From: David Marchand <david.marchand@6wind.com>
> >>
> >> - Move rte_eth_dev_create_unique_device_name() from ether/rte_ethdev.c
> to
> >> common/include/rte_pci.h as rte_eal_pci_device_name(). Being a common
> >> method, can be used across crypto/net PCI PMDs.
> >> - Remove crypto specific routine and fallback to common name function.
> >> - Introduce a eal private Update function for PCI device naming.
> >>
> >> Signed-off-by: David Marchand <david.marchand@6wind.com>
> >> [Shreyansh: Merge crypto/pci helper patches]
> >> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
> >> ---
> >> lib/librte_cryptodev/rte_cryptodev.c | 27 +++---------------
> >> lib/librte_eal/bsdapp/eal/eal_pci.c | 49
> >> +++++++++++++++++++++++++++++++++
> >> lib/librte_eal/common/eal_private.h | 13 +++++++++
> >> lib/librte_eal/common/include/rte_pci.h | 24 ++++++++++++++++
> >> lib/librte_eal/linuxapp/eal/eal_pci.c | 13 +++++++++
> >> lib/librte_ether/rte_ethdev.c | 24 +++-------------
> >> 6 files changed, 107 insertions(+), 43 deletions(-)
> >>
> >> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> >> b/lib/librte_cryptodev/rte_cryptodev.c
> >> index 2a3b649..c81e366 100644
> >> --- a/lib/librte_cryptodev/rte_cryptodev.c
> >> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> >> @@ -365,23 +365,6 @@ rte_cryptodev_pmd_allocate(const char *name, int
> >> socket_id)
> >> return cryptodev;
> >> }
> >>
> >> *
> >> * This function is private to EAL.
> >> diff --git a/lib/librte_eal/common/include/rte_pci.h
> >> b/lib/librte_eal/common/include/rte_pci.h
> >> index cf81898..e1f695f 100644
> >> --- a/lib/librte_eal/common/include/rte_pci.h
> >> +++ b/lib/librte_eal/common/include/rte_pci.h
> >> @@ -82,6 +82,7 @@ extern "C" {
> >> /** Formatting string for PCI device identifier: Ex: 0000:00:01.0 */
> >> #define PCI_PRI_FMT "%.4" PRIx16 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
> >> +#define PCI_PRI_STR_SIZE sizeof("XXXX:XX:XX.X")
> >>
> >> /** Short formatting string, without domain, for PCI device: Ex:
> >> 00:01.0 */ #define PCI_SHORT_PRI_FMT "%.2" PRIx8 ":%.2" PRIx8 ".%"
> >> PRIx8 @@ -308,6
> >>
> >> +static inline void
> >> +rte_eal_pci_device_name(const struct rte_pci_addr *addr,
> >> + char *output, size_t size)
> >> +{
> >> + RTE_VERIFY(size >= PCI_PRI_STR_SIZE);
> >> + RTE_VERIFY(snprintf(output, size, PCI_PRI_FMT,
> >> + addr->domain, addr->bus,
> >> + addr->devid, addr->function) >= 0); }
> >> +
> >>
> >> +int
> >> +pci_update_device(const struct rte_pci_addr *addr) {
> >> + char filename[PATH_MAX];
> >> +
> >> + snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT,
> >> + pci_get_sysfs_path(), addr->domain, addr->bus, addr->devid,
> >> + addr->function);
> >> +
> >> + return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
> >> + addr->function);
> >> +}
> >> +
> >
> >
> > Earlier device names were created in the format "bus:deviceid.function" as per
> the below ethdev API.
> > Now after above new eal API the name format is "domain:bus:deviceid.func"
> was that intentional and why is that so.
>
> Yes, this is intentional.
> It is to bring the naming in sync with the device name being used for scanning on
> the bus (/sys/bus/pci/devices/AAAA:BB:CC.D/).
Fair enough and thanks for clarification.
Thanks,
Reshma
^ permalink raw reply
* Re: mbuf changes
From: Morten Brørup @ 2016-10-26 9:01 UTC (permalink / raw)
To: Alejandro Lucero, Bruce Richardson; +Cc: Shreyansh Jain, dev
In-Reply-To: <CAD+H9900j7LdYH79xBBO5wfHwomagLqpwqsDjuyJxozomL-dug@mail.gmail.com>
> From: Alejandro Lucero [mailto:alejandro.lucero@netronome.com]
> On Tue, Oct 25, 2016 at 2:05 PM, Bruce Richardson <bruce.richardson@intel.com> wrote:
> > On Tue, Oct 25, 2016 at 05:24:28PM +0530, Shreyansh Jain wrote:
> > > On Monday 24 October 2016 09:55 PM, Bruce Richardson wrote:
> > > > On Mon, Oct 24, 2016 at 04:11:33PM +0000, Wiles, Keith wrote:
> > > > >
> > > > > > On Oct 24, 2016, at 10:49 AM, Morten Brørup <mb@smartsharesystems.com> wrote:
> > > > > >
> > > > > > First of all: Thanks for a great DPDK Userspace 2016!
> > > > > >
> > > > > >
> > > > > >
> > > > > > Continuing the Userspace discussion about Olivier Matz’s proposed mbuf changes...
> > > >
> > > > Thanks for keeping the discussion going!
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1.
> > > > > >
> > > > > > Stephen Hemminger had a noteworthy general comment about keeping metadata for the NIC in the appropriate section of the mbuf: Metadata generated by the NIC’s RX handler belongs in the first cache line, and metadata required by the NIC’s TX handler belongs in the second cache line. This also means that touching the second cache line on ingress should be avoided if possible; and Bruce Richardson mentioned that for this reason m->next was zeroed on free().
> > > > > >
> > > > Thinking about it, I suspect there are more fields we can reset on free
> > > > to save time on alloc. Refcnt, as discussed below is one of them, but so
> > > > too could be the nb_segs field and possibly others.
> > > >
> > > > > >
> > > > > >
> > > > > > 2.
> > > > > >
> > > > > > There seemed to be consensus that the size of m->refcnt should match the size of m->port because a packet could be duplicated on all physical ports for L3 multicast and L2 flooding.
> > > > > >
> > > > > > Furthermore, although a single physical machine (i.e. a single server) with 255 physical ports probably doesn’t exist, it might contain more than 255 virtual machines with a virtual port each, so it makes sense extending these mbuf fields from 8 to 16 bits.
> > > > >
> > > > > I thought we also talked about removing the m->port from the mbuf as it is not really needed.
> > > > >
> > > > Yes, this was mentioned, and also the option of moving the port value to
> > > > the second cacheline, but it appears that NXP are using the port value
> > > > in their NIC drivers for passing in metadata, so we'd need their
> > > > agreement on any move (or removal).
> > >
> > > I am not sure where NXP's NIC came into picture on this, but now that it is
> > > highlighted, this field is required for libevent implementation [1].
> > >
> > > A scheduler sending an event, which can be a packet, would only have
> > > information of a flow_id. From this matching it back to a port, without
> > > mbuf->port, would be very difficult (costly). There may be way around this
> > > but at least in current proposal I think port would be important to have -
> > > even if in second cache line.
> > >
> > > But, off the top of my head, as of now it is not being used for any specific
> > > purpose in NXP's PMD implementation.
> > >
> > > Even the SoC patches don't necessarily rely on it except using it because it
> > > is available.
> > >
> > > @Bruce: where did you get the NXP context here from?
> > >
> > Oh, I'm just mis-remembering. :-( It was someone else who was looking for
> > this - Netronome, perhaps?
> >
> > CC'ing Alejandro in the hope I'm remembering correctly second time
> > round!
> >
> Yes. Thanks Bruce!
>
> So Netronome uses the port field and, as I commented on the user meeting, we are happy with the field going from 8 to 16 bits.
>
> In our case, this is something some clients have demanded, and if I'm not wrong (I'll double check this asap), the port value is for knowing where the packet is coming from. Think about a switch in the NIC, with ports linked to VFs/VMs, and one or more physical ports. That port value is not related to DPDK ports but to the switch ports. Code in the host (DPDK or not) can receive packets from the wire or from VFs through the NIC. This is also true for packets received by VMs, but I guess the port value is just interested for host code.
Come to think of it: About ten years ago I was directly involved in the design of a silicon architecture for a stackable switch, and the packets on the backplane used a proprietary stack header which included a port number. Among other purposes, it allowed the management CPU to inject packets addressed to any physical port in the stack; and this could easily be more than 255 ports. I have seen similar proprietary headers in chips used for consumer wifi routers, allowing a single port on the CPU chip to communicate individually with the 4 LAN ports through the 5 port switch chip on the PCB. These are other examples of what Alejandro describes. So maybe this is quite common.
I think the Userspace consensus strongly supported increasing the m->port from 8 to 16 bit, so let's go for that. But do we keep port in the first cache line as is, do we fold it into the Flow Director part, or do we move it to the second cache line?
Maybe we should also consider that since m->port is widely used by the examples, it indicates that this variable is so fundamental that it is probably also widely used by real life applications. E.g. ingress filters in firewalls are quite useful (https://tools.ietf.org/html/bcp38).
-Morten
^ permalink raw reply
* Re: mbuf changes
From: Alejandro Lucero @ 2016-10-26 8:28 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Shreyansh Jain, dev@dpdk.org, Morten Brørup
In-Reply-To: <20161025120537.GA56680@bricha3-MOBL3.ger.corp.intel.com>
On Tue, Oct 25, 2016 at 2:05 PM, Bruce Richardson <
bruce.richardson@intel.com> wrote:
> On Tue, Oct 25, 2016 at 05:24:28PM +0530, Shreyansh Jain wrote:
> > On Monday 24 October 2016 09:55 PM, Bruce Richardson wrote:
> > > On Mon, Oct 24, 2016 at 04:11:33PM +0000, Wiles, Keith wrote:
> > > >
> > > > > On Oct 24, 2016, at 10:49 AM, Morten Brørup <
> mb@smartsharesystems.com> wrote:
> > > > >
> > > > > First of all: Thanks for a great DPDK Userspace 2016!
> > > > >
> > > > >
> > > > >
> > > > > Continuing the Userspace discussion about Olivier Matz’s proposed
> mbuf changes...
> > >
> > > Thanks for keeping the discussion going!
> > > > >
> > > > >
> > > > >
> > > > > 1.
> > > > >
> > > > > Stephen Hemminger had a noteworthy general comment about keeping
> metadata for the NIC in the appropriate section of the mbuf: Metadata
> generated by the NIC’s RX handler belongs in the first cache line, and
> metadata required by the NIC’s TX handler belongs in the second cache line.
> This also means that touching the second cache line on ingress should be
> avoided if possible; and Bruce Richardson mentioned that for this reason
> m->next was zeroed on free().
> > > > >
> > > Thinking about it, I suspect there are more fields we can reset on free
> > > to save time on alloc. Refcnt, as discussed below is one of them, but
> so
> > > too could be the nb_segs field and possibly others.
> > >
> > > > >
> > > > >
> > > > > 2.
> > > > >
> > > > > There seemed to be consensus that the size of m->refcnt should
> match the size of m->port because a packet could be duplicated on all
> physical ports for L3 multicast and L2 flooding.
> > > > >
> > > > > Furthermore, although a single physical machine (i.e. a single
> server) with 255 physical ports probably doesn’t exist, it might contain
> more than 255 virtual machines with a virtual port each, so it makes sense
> extending these mbuf fields from 8 to 16 bits.
> > > >
> > > > I thought we also talked about removing the m->port from the mbuf as
> it is not really needed.
> > > >
> > > Yes, this was mentioned, and also the option of moving the port value
> to
> > > the second cacheline, but it appears that NXP are using the port value
> > > in their NIC drivers for passing in metadata, so we'd need their
> > > agreement on any move (or removal).
> >
> > I am not sure where NXP's NIC came into picture on this, but now that it
> is
> > highlighted, this field is required for libevent implementation [1].
> >
> > A scheduler sending an event, which can be a packet, would only have
> > information of a flow_id. From this matching it back to a port, without
> > mbuf->port, would be very difficult (costly). There may be way around
> this
> > but at least in current proposal I think port would be important to have
> -
> > even if in second cache line.
> >
> > But, off the top of my head, as of now it is not being used for any
> specific
> > purpose in NXP's PMD implementation.
> >
> > Even the SoC patches don't necessarily rely on it except using it
> because it
> > is available.
> >
> > @Bruce: where did you get the NXP context here from?
> >
> Oh, I'm just mis-remembering. :-( It was someone else who was looking for
> this - Netronome, perhaps?
>
> CC'ing Alejandro in the hope I'm remembering correctly second time
> round!
>
>
Yes. Thanks Bruce!
So Netronome uses the port field and, as I commented on the user meeting,
we are happy with the field going from 8 to 16 bits.
In our case, this is something some clients have demanded, and if I'm not
wrong (I'll double check this asap), the port value is for knowing where
the packet is coming from. Think about a switch in the NIC, with ports
linked to VFs/VMs, and one or more physical ports. That port value is not
related to DPDK ports but to the switch ports. Code in the host (DPDK or
not) can receive packets from the wire or from VFs through the NIC. This is
also true for packets received by VMs, but I guess the port value is just
interested for host code.
> /Bruce
>
^ permalink raw reply
* Re: [PATCH v10 11/25] eal/pci: helpers for device name parsing/update
From: Shreyansh Jain @ 2016-10-26 6:23 UTC (permalink / raw)
To: Pattan, Reshma; +Cc: dev@dpdk.org, Thomas Monjalon, viktorin@rehivetech.com
In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F010BD36E@IRSMSX109.ger.corp.intel.com>
Hello Reshma,
On Tuesday 25 October 2016 09:19 PM, Pattan, Reshma wrote:
> Hi Shreyansh,
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Shreyansh Jain
>> Sent: Friday, September 16, 2016 5:30 AM
>> To: dev@dpdk.org
>> Cc: viktorin@rehivetech.com; David Marchand <david.marchand@6wind.com>;
>> hemant.agrawal@nxp.com; Thomas Monjalon
>> <thomas.monjalon@6wind.com>; Shreyansh Jain <shreyansh.jain@nxp.com>
>> Subject: [dpdk-dev] [PATCH v10 11/25] eal/pci: helpers for device name
>> parsing/update
>>
>> From: David Marchand <david.marchand@6wind.com>
>>
>> - Move rte_eth_dev_create_unique_device_name() from ether/rte_ethdev.c to
>> common/include/rte_pci.h as rte_eal_pci_device_name(). Being a common
>> method, can be used across crypto/net PCI PMDs.
>> - Remove crypto specific routine and fallback to common name function.
>> - Introduce a eal private Update function for PCI device naming.
>>
>> Signed-off-by: David Marchand <david.marchand@6wind.com>
>> [Shreyansh: Merge crypto/pci helper patches]
>> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
>> ---
>> lib/librte_cryptodev/rte_cryptodev.c | 27 +++---------------
>> lib/librte_eal/bsdapp/eal/eal_pci.c | 49
>> +++++++++++++++++++++++++++++++++
>> lib/librte_eal/common/eal_private.h | 13 +++++++++
>> lib/librte_eal/common/include/rte_pci.h | 24 ++++++++++++++++
>> lib/librte_eal/linuxapp/eal/eal_pci.c | 13 +++++++++
>> lib/librte_ether/rte_ethdev.c | 24 +++-------------
>> 6 files changed, 107 insertions(+), 43 deletions(-)
>>
>> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
>> b/lib/librte_cryptodev/rte_cryptodev.c
>> index 2a3b649..c81e366 100644
>> --- a/lib/librte_cryptodev/rte_cryptodev.c
>> +++ b/lib/librte_cryptodev/rte_cryptodev.c
>> @@ -365,23 +365,6 @@ rte_cryptodev_pmd_allocate(const char *name, int
>> socket_id)
>> return cryptodev;
>> }
>>
>> *
>> * This function is private to EAL.
>> diff --git a/lib/librte_eal/common/include/rte_pci.h
>> b/lib/librte_eal/common/include/rte_pci.h
>> index cf81898..e1f695f 100644
>> --- a/lib/librte_eal/common/include/rte_pci.h
>> +++ b/lib/librte_eal/common/include/rte_pci.h
>> @@ -82,6 +82,7 @@ extern "C" {
>> /** Formatting string for PCI device identifier: Ex: 0000:00:01.0 */ #define
>> PCI_PRI_FMT "%.4" PRIx16 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
>> +#define PCI_PRI_STR_SIZE sizeof("XXXX:XX:XX.X")
>>
>> /** Short formatting string, without domain, for PCI device: Ex: 00:01.0 */
>> #define PCI_SHORT_PRI_FMT "%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8 @@ -308,6
>>
>> +static inline void
>> +rte_eal_pci_device_name(const struct rte_pci_addr *addr,
>> + char *output, size_t size)
>> +{
>> + RTE_VERIFY(size >= PCI_PRI_STR_SIZE);
>> + RTE_VERIFY(snprintf(output, size, PCI_PRI_FMT,
>> + addr->domain, addr->bus,
>> + addr->devid, addr->function) >= 0); }
>> +
>>
>> +int
>> +pci_update_device(const struct rte_pci_addr *addr) {
>> + char filename[PATH_MAX];
>> +
>> + snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT,
>> + pci_get_sysfs_path(), addr->domain, addr->bus, addr->devid,
>> + addr->function);
>> +
>> + return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
>> + addr->function);
>> +}
>> +
>
>
> Earlier device names were created in the format "bus:deviceid.function" as per the below ethdev API.
> Now after above new eal API the name format is "domain:bus:deviceid.func" was that intentional and why is that so.
Yes, this is intentional.
It is to bring the naming in sync with the device name being used for
scanning on the bus (/sys/bus/pci/devices/AAAA:BB:CC.D/).
Also, it was proposed in a separate patch [1] but merged in this series.
[1] http://dpdk.org/ml/archives/dev/2016-July/044614.html
(Just as a note: I am not the original author of this patch but above is
what I understood and acked it).
>
>> -static int
>> -rte_eth_dev_create_unique_device_name(char *name, size_t size,
>> - struct rte_pci_device *pci_dev)
>> -{
>> - int ret;
>> -
>> - ret = snprintf(name, size, "%d:%d.%d",
>> - pci_dev->addr.bus, pci_dev->addr.devid,
>> - pci_dev->addr.function);
>> - if (ret < 0)
>> - return ret;
>> - return 0;
>> -}
>> -
>
-
Shreyansh
^ permalink raw reply
* Re: DPDK & ASLR
From: Jon DeVree @ 2016-10-26 4:20 UTC (permalink / raw)
To: dev
In-Reply-To: <CAJacC6ttgyPYSXYSO0EdHmWNLwLrzwC86Pex5bO5KS92LOd8_A@mail.gmail.com>
On Tue, Oct 25, 2016 at 15:18:03 -0700, Samir Shah wrote:
> Does ASLR need to be turned off system-wide, or DPDK-processes wide? Could
> we use setarch/personality to disable ASLR for just the DPDK process and
> leave it enabled for the rest of the system? Any experience to say if that
> would work or not?
>
I'm using setarch/personality to disable it only in the processes using
dpdk without any trouble.
--
Jon
Doge Wrangler
X(7): A program for managing terminal windows. See also screen(1) and tmux(1).
^ permalink raw reply
* Re: [PATCH v7 3/7] vhost: simplify mergeable Rx vring reservation
From: Yuanhan Liu @ 2016-10-26 2:56 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
In-Reply-To: <4827637.JFOYA5HLyK@xps13>
On Wed, Oct 26, 2016 at 12:08:49AM +0200, Thomas Monjalon wrote:
> 2016-10-14 17:34, Yuanhan Liu:
> > -static inline uint32_t __attribute__((always_inline))
> > +static inline int __attribute__((always_inline))
> > copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
> > - uint16_t end_idx, struct rte_mbuf *m,
> > - struct buf_vector *buf_vec)
> > + struct rte_mbuf *m, struct buf_vector *buf_vec,
> > + uint16_t num_buffers)
> > {
> > struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0};
> > uint32_t vec_idx = 0;
> > - uint16_t start_idx = vq->last_used_idx;
> > - uint16_t cur_idx = start_idx;
> > + uint16_t cur_idx = vq->last_used_idx;
> > uint64_t desc_addr;
> > uint32_t desc_chain_head;
> > uint32_t desc_chain_len;
> > @@ -394,21 +393,21 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
> > struct rte_mbuf *hdr_mbuf;
> >
> > if (unlikely(m == NULL))
> > - return 0;
> > + return -1;
> >
> > LOG_DEBUG(VHOST_DATA, "(%d) current index %d | end index %d\n",
> > dev->vid, cur_idx, end_idx);
>
> There is a build error:
> lib/librte_vhost/virtio_net.c:399:22: error: ‘end_idx’ undeclared
Oops... you know, my robot is broken since the holiday :(
I just had a quick fix. Hopefully, it will start working again...
> It is probably trivial and could be fixed directly in the already applied
> commit in next-virtio.
Yes, and FYI, here is the overall diffs I made to fix this bug.
--yliu
---
diff --git a/lib/librte_vhost/virtio_net.c
b/lib/librte_vhost/virtio_net.c
index b784dba..eed0b1c 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -443,9 +443,6 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev,
struct rte_mbuf *m,
if (unlikely(m == NULL))
return -1;
- LOG_DEBUG(VHOST_DATA, "(%d) current index %d | end index %d\n",
- dev->vid, cur_idx, end_idx);
-
desc_addr = gpa_to_vva(dev, buf_vec[vec_idx].buf_addr);
if (buf_vec[vec_idx].buf_len < dev->vhost_hlen || !desc_addr)
return -1;
@@ -555,6 +552,10 @@ virtio_dev_merge_rx(struct virtio_net *dev,
uint16_t queue_id,
break;
}
+ LOG_DEBUG(VHOST_DATA, "(%d) current index %d | end index %d\n",
+ dev->vid, vq->last_avail_idx,
+ vq->last_avail_idx + num_buffers);
+
if (copy_mbuf_to_desc_mergeable(dev, pkts[pkt_idx],
buf_vec, num_buffers) < 0) {
vq->shadow_used_idx -= num_buffers;
^ permalink raw reply
* Re: [PATCH] examples/ipsec-secgw: Update checksum while decrementing ttl
From: De Lara Guarch, Pablo @ 2016-10-26 2:29 UTC (permalink / raw)
To: Akhil Goyal, Gonzalez Monroy, Sergio, dev@dpdk.org
In-Reply-To: <DB3PR04MB10743C10BC39E6D154FA82DE6D20@DB3PR04MB107.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Wednesday, October 19, 2016 1:38 AM
> To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio; dev@dpdk.org
> Subject: RE: [PATCH] examples/ipsec-secgw: Update checksum while
> decrementing ttl
>
>
>
> -----Original Message-----
> From: De Lara Guarch, Pablo [mailto:pablo.de.lara.guarch@intel.com]
> Sent: Monday, October 17, 2016 10:35 PM
> To: Gonzalez Monroy, Sergio <sergio.gonzalez.monroy@intel.com>; Akhil
> Goyal <akhil.goyal@nxp.com>; dev@dpdk.org
> Subject: RE: [PATCH] examples/ipsec-secgw: Update checksum while
> decrementing ttl
>
>
>
> > -----Original Message-----
> > From: Gonzalez Monroy, Sergio
> > Sent: Monday, October 10, 2016 5:05 AM
> > To: De Lara Guarch, Pablo; Akhil Goyal; dev@dpdk.org
> > Subject: Re: [PATCH] examples/ipsec-secgw: Update checksum while
> > decrementing ttl
> >
> > On 07/10/2016 21:53, De Lara Guarch, Pablo wrote:
> > >> -----Original Message-----
> > >> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> > >> Sent: Tuesday, October 04, 2016 11:33 PM
> > >> To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio; dev@dpdk.org
> > >> Subject: Re: [PATCH] examples/ipsec-secgw: Update checksum while
> > >> decrementing ttl
> > >>
> > >> On 10/5/2016 6:04 AM, De Lara Guarch, Pablo wrote:
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Sergio
> > Gonzalez
> > >>>> Monroy
> > >>>> Sent: Monday, September 26, 2016 6:28 AM
> > >>>> To: akhil.goyal@nxp.com; dev@dpdk.org
> > >>>> Subject: Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: Update
> > checksum
> > >>>> while decrementing ttl
> > >>>>
> > >>>> Hi Akhil,
> > >>>>
> > >>>> This application relies on checksum offload in both outbound and
> > >> inbound
> > >>>> paths (PKT_TX_IP_CKSUM flag).
> > >> [Akhil]Agreed that the application relies on checksum offload, but
> > >> here we are talking about the inner ip header. Inner IP checksum
> > >> will be updated on the next end point after decryption. This would
> > >> expect that the next end point must have checksum offload
> > >> capability. What if we are capturing the encrypted packets on
> > >> wireshark or say send it to some other machine which does not run
> > >> DPDK and do not know about
> > checksum
> > >> offload, then wireshark/other machine will not be able to get the
> > >> correct the checksum and will show error.
> >
> > Understood, we need to have a valid inner checksum.
> > RFC1624 states that the computation would be incorrect in
> > corner/boundary case.
> > I reckon you are basing your incremental update on RFC1141?
> >
> > Also I think you should take care of endianess and increment the
> > checksum with
> > host_to_be(0x0100) instead of +1.
> >
> > >>>> Because we assume that we always forward the packet in both
> > >>>> paths,
> > we
> > >>>> decrement the ttl in both inbound and outbound.
> > >>>> You seem to only increment (recalculate) the checksum of the
> > >>>> inner IP header in the outbound path but not the inbound path.
> > >> [Akhil]Correct I missed out the inbound path.
> > >>>> Also, in the inbound path you have to consider a possible ECN
> > >>>> value
> > >> update.
> > >> [Akhil]If I take care of the ECN then it would mean I need to
> > >> calculate the checksum completely, incremental checksum wont give
> correct results.
> > >> This would surely impact performance. Any suggestion on how should
> > >> we take care of ECN update. Should I recalculate the checksum and
> > >> send the patch for ECN update? Or do we have a better solution.
> >
> > If I am understanding the RFCs mentioned above correctly, you should
> > be able to do incremental checksum update for any 16bit field/value of
> > the IP header.
> > I don't see no reason why you couldn't do something like that, except
> > that you would have to follow the full equation instead of just adding
> > 0x0100, which would be always the case when decrementing TTL.
> >
> > What do you think?
>
> Any comments, Akhil?
>
> Ok.. will send next version soon.
Hi Akhil,
Are you sending that version soon? It won't make it the RC2, but it may be merged for RC3.
Thanks,
Pablo
^ permalink raw reply
* DPDK & ASLR
From: Samir Shah @ 2016-10-25 22:18 UTC (permalink / raw)
To: dev
We know that it is recommended that ASLR be turned off so that the mappings
across primary and secondary remain the same.
Does ASLR need to be turned off system-wide, or DPDK-processes wide? Could
we use setarch/personality to disable ASLR for just the DPDK process and
leave it enabled for the rest of the system? Any experience to say if that
would work or not?
- Samir
^ permalink raw reply
* Re: [PATCH v7 3/7] vhost: simplify mergeable Rx vring reservation
From: Thomas Monjalon @ 2016-10-25 22:08 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev
In-Reply-To: <1476437678-7102-4-git-send-email-yuanhan.liu@linux.intel.com>
2016-10-14 17:34, Yuanhan Liu:
> -static inline uint32_t __attribute__((always_inline))
> +static inline int __attribute__((always_inline))
> copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
> - uint16_t end_idx, struct rte_mbuf *m,
> - struct buf_vector *buf_vec)
> + struct rte_mbuf *m, struct buf_vector *buf_vec,
> + uint16_t num_buffers)
> {
> struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0};
> uint32_t vec_idx = 0;
> - uint16_t start_idx = vq->last_used_idx;
> - uint16_t cur_idx = start_idx;
> + uint16_t cur_idx = vq->last_used_idx;
> uint64_t desc_addr;
> uint32_t desc_chain_head;
> uint32_t desc_chain_len;
> @@ -394,21 +393,21 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
> struct rte_mbuf *hdr_mbuf;
>
> if (unlikely(m == NULL))
> - return 0;
> + return -1;
>
> LOG_DEBUG(VHOST_DATA, "(%d) current index %d | end index %d\n",
> dev->vid, cur_idx, end_idx);
There is a build error:
lib/librte_vhost/virtio_net.c:399:22: error: ‘end_idx’ undeclared
It is probably trivial and could be fixed directly in the already applied
commit in next-virtio.
^ permalink raw reply
* [PATCH] pci: Don't call probe callback if driver already loaded.
From: Ben Walker @ 2016-10-25 21:50 UTC (permalink / raw)
To: dev
If the user asks to probe multiple times, the probe
callback should only be called on devices that don't have
a driver already loaded.
This is useful if a driver is registered after the
execution of a program has started and the list of devices
needs to be re-scanned.
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
---
lib/librte_eal/common/eal_common_pci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_pci.c b/lib/librte_eal/common/eal_common_pci.c
index 638cd86..971ad20 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -289,6 +289,10 @@ pci_probe_all_drivers(struct rte_pci_device *dev)
if (dev == NULL)
return -1;
+ /* Check if a driver is already loaded */
+ if (dev->driver != NULL)
+ return 0;
+
TAILQ_FOREACH(dr, &pci_driver_list, next) {
rc = rte_eal_pci_probe_one_driver(dr, dev);
if (rc < 0)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] lib/ether: prevent duplicate callback on list
From: Thomas Monjalon @ 2016-10-25 21:35 UTC (permalink / raw)
To: E. Scott Daniels; +Cc: dev
In-Reply-To: <1476970481-21034-1-git-send-email-daniels@research.att.com>
2016-10-20 09:34, E. Scott Daniels:
> This change prevents the attempt to add a structure which is
> already on the callback list. If a struct with matching
> parameters is found on the list, then no action is taken. If
> a struct with matching parameters is found on the list, then
> no action is taken.
Callback is not duplicate anymore but the last sentence is duplicate :)
> Fixes: ac2f69c ("ethdev: fix crash if malloc of user callback fails")
>
> Signed-off-by: E. Scott Daniels <daniels@research.att.com>
> ---
>
> V2:
> * Correct the component name; changed from net/ixgbe.
> * Add Fixes tag.
> * Acked-by: Wenzhuo Lu <Wenzhuo.lu@intel.com>
The Acked-by tag must be added below your Signed-off-by.
Applied with above nits fixed, thanks
^ permalink raw reply
* Re: [dpdk-stable] [PATCH v2] mempool: fix search of maximum contiguous pages
From: Thomas Monjalon @ 2016-10-25 21:23 UTC (permalink / raw)
To: Olivier Matz, wei.dai; +Cc: dev, stable
In-Reply-To: <1477407671-21019-1-git-send-email-olivier.matz@6wind.com>
2016-10-25 17:01, Olivier Matz:
> From: Wei Dai <wei.dai@intel.com>
>
> paddr[i] + pg_sz always points to the start physical address of the
> 2nd page after pddr[i], so only up to 2 pages can be combinded to
> be used. With this revision, more than 2 pages can be used.
>
> Fixes: 84121f197187 ("mempool: store memory chunks in a list")
>
> Signed-off-by: Wei Dai <wei.dai@intel.com>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] testpmd: fix fdir command on MAC and tunnel modes
From: Thomas Monjalon @ 2016-10-25 21:14 UTC (permalink / raw)
To: Frederico Cadete, Frederico.Cadete-ext@oneaccess-net.com; +Cc: dev
In-Reply-To: <CAL5ScNVyW=UU9A_X6BJ+BA53bkae=4W-OLqO31FHQgEynNHmsw@mail.gmail.com>
2016-09-27 11:01, Frederico Cadete:
> On Tue, Sep 27, 2016 at 4:42 AM, Wu, Jingjing <jingjing.wu@intel.com> wrote:
> > From: Frederico.Cadete-
> >> The flow_director_filter commands has a pf|vf option for most modes
> >> except for MAC-VLAN and tunnel. On Intel NIC's these modes are not
> >> supported under virtualized environments.
> >> But the application was checking that this field was parsed for these cases,
> >> even though this token is not registered with the cmdline parser.
> >>
> >> This patch skips checking of this field for the commands that don't accept it.
> >>
> >> Signed-off-by: Frederico Cadete <Frederico.Cadete-ext@oneaccess-net.com>
[...]
> >
> > Thanks for the patch.
>
> And thanks a lot for the review.
>
> > But with this change the field of pf_vf cannot omit either.
> > I think it still looks confused because it will allow any meaningless string.
>
> Sorry, I am not aware that it can be omitted.
> For MAC/VLAN and tunnel mode it does not and will not allow any
> meaningless string.
> At least that was my intention :)
>
> The cmdline parser expects "... flexbytes (flexbytes_value) (drop|fwd)
> queue ..." .
> This is what is documented [1] and the command's cmdline_parse_inst_t
> [2] matches this.
> If you put something in-between "(drop|fwd)" and "queue" it is
> rejected by the parser
> in librte_cmdline.
>
> > In MAC_VLAN or TUNNEL mode, why not just use pf.
>
> With the current code, because if you write that in the command, it is
> rejected by the parser :)
>
> Do you mean it would be preferable to make these commands always take
> such an argument,
> and only at the NIC driver check that it must equal PF for MAC_VLAN or
> TUNNEL mode?
> The command becomes a bit more complicated for the current intel
> NIC's, but as I understand
> it currently does not work anyway. Unless I'm missing something else.
>
> >
> > Maybe an optional field supporting on DPDK cmdline library is exactly what we
> > Are waiting for :)
>
> Laudable goal! My excuses but it's beyond my current skills and bandwith :/
Thanks Frederico.
Your approach has been re-submitted and fixed by Wenzhuo:
http://dpdk.org/patch/16679
^ permalink raw reply
* Re: [PATCH v2] app/testpmd: fix PF/VF check of flow director
From: Thomas Monjalon @ 2016-10-25 21:08 UTC (permalink / raw)
To: Wenzhuo Lu; +Cc: dev
In-Reply-To: <1476839535-1220-1-git-send-email-wenzhuo.lu@intel.com>
2016-10-19 09:12, Wenzhuo Lu:
> Parameters pf & vf are added into most of flow director
> filter CLIs.
> But mac-valn and tunnel filters don't have these parameters,
> the parameters should not be checked for mac-vlan and tunnel
> filters.
>
> Fixes: e6a68c013353 ("app/testpmd: extend commands for flow director in VF")
>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
This bug was reported and fixed by Frederico Cadete:
http://dpdk.org/patch/15264
We have waited long to have a review saying it requires
an optional parameter in the command line.
And finally you re-post a fixed version of the same approach
without any comment to the original thread or a reference here.
Please be more careful with occasional contributors.
Applied with
Reported-by: Frederico Cadete <frederico.cadete-ext@oneaccess-net.com>
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-10-25 17:49 UTC (permalink / raw)
To: dev
Cc: thomas.monjalon, bruce.richardson, narender.vangati,
hemant.agrawal, gage.eads
In-Reply-To: <1476214216-31982-1-git-send-email-jerin.jacob@caviumnetworks.com>
On Wed, Oct 12, 2016 at 01:00:16AM +0530, Jerin Jacob wrote:
> Thanks to Intel and NXP folks for the positive and constructive feedback
> I've received so far. Here is the updated RFC(v2).
>
> I've attempted to address as many comments as possible.
>
> This series adds rte_eventdev.h to the DPDK tree with
> adequate documentation in doxygen format.
>
> Updates are also available online:
>
> Related draft header file (this patch):
> https://rawgit.com/jerinjacobk/libeventdev/master/rte_eventdev.h
>
> PDF version(doxgen output):
> https://rawgit.com/jerinjacobk/libeventdev/master/librte_eventdev_v2.pdf
>
> Repo:
> https://github.com/jerinjacobk/libeventdev
>
Hi Community,
So far, I have received constructive feedback from Intel, NXP and Linaro folks.
Let me know, if anyone else interested in contributing to the definition of eventdev?
If there are no major issues in proposed spec, then Cavium would like work on
implementing and up-streaming the common code(lib/librte_eventdev/) and
an associated HW driver.(Requested minor changes of v2 will be addressed
in next version).
We are planning to submit the work for 17.02 or 17.05 release(based on
how implementation goes).
/Jerin
Cavium
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox