Re: [dpdk-dev] [PATCH] doc: add change notice for mbuf sched field
On Tue, Feb 13, 2018 at 09:20:48AM +0530, Hemant Agrawal wrote: > On 2/10/2018 6:18 PM, Jerin Jacob wrote: > > -Original Message- > > > Date: Fri, 9 Feb 2018 16:45:16 + > > > From: Cristian Dumitrescu > > > To: dev@dpdk.org > > > CC: olivier.m...@6wind.com, tho...@monjalon.net, > > > jasvinder.si...@intel.com, > > > roy.fan.zh...@intel.com, kevin.la...@intel.com > > > Subject: [dpdk-dev] [PATCH] doc: add change notice for mbuf sched field > > > X-Mailer: git-send-email 2.7.4 > > > > > > Signed-off-by: Cristian Dumitrescu > > > Acked-by: Jasvinder Singh > > > Acked-by: Roy Fan Zhang > > > Acked-by: Kevin Laatz > > > > Acked-by: Jerin Jacob > > Acked-by: Hemant Agrawal Acked-by: Olivier Matz
[dpdk-dev] [PATCH v2] net/tap: add CRC stripping capability
CRC stripping is executed in the kernel outside of TAP PMD scope.
There is no prevention that the TAP PMD will report on Rx CRC
stripping capability.
In the corrupted code, TAP PMD did not report on this capability.
The fix enables TAP PMD to report that Rx CRC stripping is supported.
Fixes: 02f96a0a82d1 ("net/tap: add TUN/TAP device PMD")
Cc: sta...@dpdk.org
Signed-off-by: Ophir Munk
---
v2: updated commit message
drivers/net/tap/rte_eth_tap.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index 9d39384..f09db0e 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -261,7 +261,8 @@ tap_rx_offload_get_port_capa(void)
return DEV_RX_OFFLOAD_SCATTER |
DEV_RX_OFFLOAD_IPV4_CKSUM |
DEV_RX_OFFLOAD_UDP_CKSUM |
- DEV_RX_OFFLOAD_TCP_CKSUM;
+ DEV_RX_OFFLOAD_TCP_CKSUM |
+ DEV_RX_OFFLOAD_CRC_STRIP;
}
static uint64_t
@@ -270,7 +271,8 @@ tap_rx_offload_get_queue_capa(void)
return DEV_RX_OFFLOAD_SCATTER |
DEV_RX_OFFLOAD_IPV4_CKSUM |
DEV_RX_OFFLOAD_UDP_CKSUM |
- DEV_RX_OFFLOAD_TCP_CKSUM;
+ DEV_RX_OFFLOAD_TCP_CKSUM |
+ DEV_RX_OFFLOAD_CRC_STRIP;
}
static bool
--
2.7.4
Re: [dpdk-dev] [PATCH] example exception_path: cache align per CPU stats
Patch ought to also have:
Fixes: af75078fece3 ("first public release")
Otherwise looks good to me. I'm not the maintainer so have only done
basic smoke tests.
On 13/02/2018 03:43, Dustin Lundquist wrote:
[..]
Signed-off-by: Dustin Lundquist
---
examples/exception_path/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Remy Horton
Re: [dpdk-dev] [PATCH v2 1/3] net/virtio: fix mbuf data offset for simple Rx function
On 02/12/2018 04:46 PM, Maxime Coquelin wrote:
From: Olivier Matz
The mbuf->data_off was was not properly set for the first received
mbufs. Fix this by setting it in virtqueue_enqueue_recv_refill_simple(),
which is used to enqueue the first mbuf in the ring.
The function virtio_rxq_rearm_vec(), which is used to rearm the ring
with new mbufs, is valid and does not need to be updated.
Fixes: cab0461234e7 ("virtio: fill Rx avail ring with blank mbufs")
Cc: sta...@dpdk.org
Signed-off-by: Olivier Matz
---
drivers/net/virtio/virtio_rxtx_simple.c | 1 +
1 file changed, 1 insertion(+)
I forgot to apply my r-b when re-posting:
Reviewed-by: Maxime Coquelin
Maxime
[dpdk-dev] [PATCH v2] doc: add maintainers section to the contributors guide
Add a maintainers section to the contributors guide to have a low tech location to check/link to the current maintainers. This file is included dynamically from the MAINTAINERS file in the root directory of the DPDK source when the docs are built. This also allows us to link to the file from other sections of the docs. Signed-off-by: Ciara Power --- doc/guides/contributing/patches.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst index 3c2f310..2287835 100644 --- a/doc/guides/contributing/patches.rst +++ b/doc/guides/contributing/patches.rst @@ -551,3 +551,12 @@ patch accepted. The general cycle for patch review and acceptance is: than rework of the original. * Trivial patches may be merged sooner than described above at the tree committer's discretion. + +DPDK Maintainers + + +The following are the DPDK maintainers as listed in the ``MAINTAINERS`` file +in the DPDK root directory. + +.. literalinclude:: ../../../MAINTAINERS + :lines: 3- -- 2.7.4 -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: [dpdk-dev] [PATCH] doc: improve HTML spacing in release notes
> -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Monday, February 12, 2018 5:45 PM > To: Mcnamara, John > Cc: dev@dpdk.org > Subject: [PATCH] doc: improve HTML spacing in release notes > > Vertical spacing is lower before an item title than after. > So the items with paragraphs are not well separated. > > A custom CSS is added to override the rtd theme. > That's great. It fixes a long standing irritation with the formatting of the release notes, and other lists. Also, it gives us the opportunity to improve the CSS in other ways. Acked-by: John McNamara
Re: [dpdk-dev] [PATCH 07/14] net/virtio: implement transmit path for packed queues
On Mon, Feb 12, 2018 at 09:16:27PM +0800, Jason Wang wrote:
On 2018???01???29??? 22:11, Jens Freimann wrote:
+/* Cleanup from completed transmits. */
+static void
+virtio_xmit_cleanup(struct virtqueue *vq)
+{
+ uint16_t idx;
+ uint16_t size = vq->vq_nentries;
+ struct vring_desc_1_1 *desc = vq->vq_ring.desc_1_1;
+
+ idx = vq->vq_used_cons_idx & (size - 1);
+ while (desc_is_used(&desc[idx]) &&
+ vq->vq_free_cnt < size) {
+ while (desc[idx].flags & VRING_DESC_F_NEXT) {
+ vq->vq_free_cnt++;
+ idx = ++vq->vq_used_cons_idx & (size - 1);
+ }
+ vq->vq_free_cnt++;
+ idx = ++vq->vq_used_cons_idx & (size - 1);
+ }
+}
This looks like a violation of the spec. In 2.6.6 Next Flag:
Descriptor Chaining. It said:
"VIRTQ_DESC_F_NEXT is reserved in used descriptors, and should be
ignored by drivers."
I think you are right. I will rework this bit.
(Looking at the device implementation, it was in fact an in order
device which is said to be no in the cover).
Looking into this as well.
Thanks for the review!
regards,
Jens
Re: [dpdk-dev] [RFC v2, 2/2] eventdev: add crypto adapter API header
A gentle remainder for review :) -Abhinandan > -Original Message- > From: Gujjar, Abhinandan S > Sent: Monday, January 15, 2018 4:24 PM > To: jerin.ja...@caviumnetworks.com > Cc: dev@dpdk.org; Vangati, Narender ; Gujjar, > Abhinandan S ; Rao, Nikhil > ; Eads, Gage > Subject: [RFC v2, 2/2] eventdev: add crypto adapter API header > > Add crypto event adapter APIs to support packet transfer mechanism between > cryptodev and event device. > > Signed-off-by: Abhinandan Gujjar > Signed-off-by: Nikhil Rao > Signed-off-by: Gage Eads > --- > Notes: > V2: > 1. Updated type as ENQ-DEQ in rte_event_crypto_adapter_type > 2. Removed enum rte_event_crypto_conf_type > 3. Updated struct rte_event_crypto_metadata > 4. Removed struct rte_event_crypto_queue_pair_conf > 5. Updated rte_event_crypto_adapter_queue_pair_add() API > > lib/librte_eventdev/Makefile | 1 + > lib/librte_eventdev/rte_event_crypto_adapter.h | 452 > + > 2 files changed, 453 insertions(+) > create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h > > diff --git a/lib/librte_eventdev/Makefile b/lib/librte_eventdev/Makefile index > 7fd78c7..a5a6214 100644 > --- a/lib/librte_eventdev/Makefile > +++ b/lib/librte_eventdev/Makefile > @@ -27,6 +27,7 @@ SYMLINK-y-include += rte_eventdev_pmd_pci.h SYMLINK- > y-include += rte_eventdev_pmd_vdev.h SYMLINK-y-include += rte_event_ring.h > SYMLINK-y-include += rte_event_eth_rx_adapter.h > +SYMLINK-y-include += rte_event_crypto_adapter.h > > # versioning export map > EXPORT_MAP := rte_eventdev_version.map > diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h > b/lib/librte_eventdev/rte_event_crypto_adapter.h > new file mode 100644 > index 000..e90b57e > --- /dev/null > +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h > @@ -0,0 +1,452 @@ > +/* > + * Copyright(c) 2018 Intel Corporation. All rights reserved. > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * > + * * Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * * Redistributions in binary form must reproduce the above copyright > + * notice, this list of conditions and the following disclaimer in > + * the documentation and/or other materials provided with the > + * distribution. > + * * Neither the name of Intel Corporation nor the names of its > + * contributors may be used to endorse or promote products derived > + * from this software without specific prior written permission. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND > CONTRIBUTORS > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND > FITNESS FOR > + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE > COPYRIGHT > + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, > INCIDENTAL, > + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > NOT > + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS > OF USE, > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND > ON ANY > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR > TORT > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF > THE USE > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH > DAMAGE. > + */ > + > +#ifndef _RTE_EVENT_CRYPTO_ADAPTER_ > +#define _RTE_EVENT_CRYPTO_ADAPTER_ > + > +/** > + * This adapter adds support to enqueue crypto completions to event device. > + * The packet flow from cryptodev to the event device can be > +accomplished > + * using both SW and HW based transfer mechanisms. > + * The adapter uses a EAL service core function for SW based packet > +transfer > + * and uses the eventdev PMD functions to configure HW based packet > +transfer > + * between the cryptodev and the event device. > + * > + * In the case of SW based transfers, application can choose to submit > +a > + * crypto operation directly to cryptodev or send it to the cryptodev > + * adapter via eventdev, the cryptodev adapter then submits the crypto > + * operation to the crypto device. The first mode is known as the > + * dequeue only (DEQ) mode and the second as the enqueue - dequeue > + * (ENQ_DEQ) mode. The choice of mode can be specified when creating > + * the adapter. > + * In the latter choice, the cryptodev adapter is able to use > + * RTE_OP_FORWARD as the event dev enqueue type, this has a performance > + * advantage in "closed system" eventdevs like the eventdev SW PMD and > + * also, the event cannot be dropped. > + * > + * In the ENQ_DEQ mode the application needs to specify the cryptodev > +ID > + * and queue
Re: [dpdk-dev] [RFC v3, 1/3] cryptodev: set private data for session-less mode
A gentle remainder for review :)
-Abhinandan
> -Original Message-
> From: Gujjar, Abhinandan S
> Sent: Thursday, February 1, 2018 3:00 PM
> To: Doherty, Declan ; akhil.go...@nxp.com; De
> Lara Guarch, Pablo ;
> jerin.jacobkollanukka...@cavium.com
> Cc: dev@dpdk.org; Vangati, Narender ; Gujjar,
> Abhinandan S ; Rao, Nikhil
>
> Subject: [RFC v3, 1/3] cryptodev: set private data for session-less mode
>
> The application may want to store private data along with the rte_crypto_op
> that is transparent to the rte_cryptodev layer.
> For e.g., If an eventdev based application is submitting a crypto session-less
> operation and wants to indicate event information required to construct a new
> event that will be enqueued to eventdev after completion of the crypto
> operation. This patch provides a mechanism for the application to associate
> this
> information with the rte_crypto_op in session-less mode.
>
> Signed-off-by: Abhinandan Gujjar
> Signed-off-by: Nikhil Rao
> ---
> Notes:
> V3:
> 1. Added separate patch for session-less private data
> 2. Added more information on offset
> V2:
> 1. Removed enum rte_crypto_op_private_data_type
> 2. Corrected formatting
>
> lib/librte_cryptodev/rte_crypto.h | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_cryptodev/rte_crypto.h
> b/lib/librte_cryptodev/rte_crypto.h
> index 95cf861..2540426 100644
> --- a/lib/librte_cryptodev/rte_crypto.h
> +++ b/lib/librte_cryptodev/rte_crypto.h
> @@ -84,8 +84,14 @@ struct rte_crypto_op {
>*/
> uint8_t sess_type;
> /**< operation session type */
> + uint16_t private_data_offset;
> + /**< Offset to indicate start of private data (if any). The offset
> + * is counted from the start of the rte_crypto_op including IV.
> + * The private data may be used by the application to store
> + * information which should remain untouched in the library/driver
> + */
>
> - uint8_t reserved[5];
> + uint8_t reserved[3];
> /**< Reserved bytes to fill 64 bits for future additions */
> struct rte_mempool *mempool;
> /**< crypto operation mempool which operation is allocated from */
> --
> 1.9.1
Re: [dpdk-dev] [PATCH] igb_uio: fix uevent montior issue
On 2/12/2018 8:28 AM, Guo, Jia wrote:
>
>
> On 2/9/2018 6:01 AM, Thomas Monjalon wrote:
>> 30/01/2018 11:01, Jeff Guo:
>>> udev could not detect remove and add event of device when hotplug in
>>> and out devices, that related with the fix about using pointer of
>>> rte_uio_pci_dev as dev_id instead of uio_device for irq device handler,
>>> that would result igb uio irq failure when kernel version after than 3.17.
>>> so this patch correct it by use kernel version check before handle the
>>> pci interrupt.
>>>
>>> Fixes: 6b9ed026a870 ("igb_uio: fix build with kernel <= 3.17")
>>> Signed-off-by: Jeff Guo
>>> ---
>>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
>>> struct rte_uio_pci_dev *udev = (struct rte_uio_pci_dev *)dev_id;
>>> struct uio_info *info = &udev->info;
>>> -
>>> +#else
>>> + struct uio_device *idev = (struct uio_device *)dev_id;
>>> + struct uio_info *info = idev->info;
>>> + struct rte_uio_pci_dev *udev = info->priv;
>>> +#endif
>> Can we avoid checking Linux version number?
>> This method won't work with kernel backports.
> i don't think that is a bug rather than a kernel feature parameter
> change , so i am not sure if it will definitely a chance exist for the
> kernel backport fix for that.
Hi Jeff,
What we tend to do is add version check to compat.h and define a feature based
on that check and use feature define in .c . This makes .c file more readable
and if in the future we need to add more check because of backported kernels
(mostly we need to do) that checks all goes into compat.h and .c file remains
clean.
Thanks,
ferruh
Re: [dpdk-dev] [PATCH] doc: improve HTML spacing in release notes
13/02/2018 10:09, Mcnamara, John: > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > Vertical spacing is lower before an item title than after. > > So the items with paragraphs are not well separated. > > > > A custom CSS is added to override the rtd theme. > > That's great. It fixes a long standing irritation with the formatting > of the release notes, and other lists. Me too, I was irritated about this formatting :) But I never tried to fix it until you talked about it with me. Conclusion: we must communicate about our frustrations ;) > Also, it gives us the opportunity to improve the CSS in other ways. Yes, this custom CSS can be extended.
Re: [dpdk-dev] [PATCH v3] ethdev: fix ethdev data alignment
On 2/12/2018 2:11 PM, Jerin Jacob wrote:
> -Original Message-
>> Date: Mon, 12 Feb 2018 14:02:17 +
>> From: Matan Azrad
>> To: Jerin Jacob
>> CC: "dev@dpdk.org" , "ferruh.yi...@intel.com"
>> , "sta...@dpdk.org" , Thomas
>> Monjalon , Konstantin Ananyev
>> , Pavan Nikhilesh
>>
>> Subject: RE: [dpdk-dev] [PATCH v3] ethdev: fix ethdev data alignment
>>
>>
>>
>> From: Jerin Jacob, Sent: Monday, February 12, 2018 3:51 PM
>>> -Original Message-
Date: Mon, 12 Feb 2018 13:44:54 +
From: Matan Azrad
To: Jerin Jacob , "dev@dpdk.org"
CC: "ferruh.yi...@intel.com" , "sta...@dpdk.org"
, Thomas Monjalon ,
>>> Konstantin
Ananyev , Pavan Nikhilesh
Subject: RE: [dpdk-dev] [PATCH v3] ethdev: fix ethdev data alignment
Hi Jerin
From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> The struct rte_eth_dev_data is used in ethdev fastpath routines and
> it not aligned to cache line size. This patch fixes the ethdev data
>>> alignment.
>
> The alignment was broken from the "first public release" changeset
> where ethdev data address was aligned only to the first port.
> Remaining ports alignment was defined by the size of the struct
> (rte_eth_dev_data). This scheme is not guaranteed to be cache line
> aligned all the time.
>
> "ethdev: add port ownership" change set introduced a
> rte_eth_dev_shared_data container for port ownership change, This
> resulted in rte_eth_dev->data memory for the first port also as
> cache unaligned.
>
> Added a compiler alignment attribute to make sure rte_eth_dev->data
> always cache aligned so that CPU/compiler
> 1) Avoid sharing the element with another cache line
> 2) Can load/store the elements in struct rte_eth_dev_data as
> naturally aligned.
>
> Some platform like thunderX could see performance regression of 1%
> at
> "ethdev: add port ownership" change set with
> 1 port/1 queue l3fwd application and this patch fixes that regression.
>
> example command:
> sudo ./examples/l3fwd/build/l3fwd -c 0xff00 -- -p 0x1 --config="(0,0,9)"
>
> Fixes: af75078fece3 ("first public release")
> Fixes: 5b7ba31148a8 ("ethdev: add port ownership")
I don't think you need the add the 5b7ba31148a8 fix line.
Maybe think about it in the next way:
Is your fix can stay as a same fix before the port ownership feature
>>> addition?
If yes, You are not fixing it.
>>>
>>> I don't think so. 5b7ba31148a8 breaking the first port alignment case(as
>>> mentioned in the commit log clearly).
>>> First port alignment was correct prior to 5b7ba31148a8 change set
>>>
>>> Do you agree?
>>
>> No.
>> The root cause of the issue this fix is fixing, is that the structure is not
>> aligned, it is not relevant to port ownership.
>> The port ownership just exposes it.
>
> My point is simple. First port alignment was correct prior to 5b7ba31148a8
> change set.
> it is broken from there.
+1 for this logic, adding fixes line makes sense for me.
>
> It is minor thing. I let, ethdev maintainer to decide what to added in Fixes
> on apply.
>
Re: [dpdk-dev] [PATCH v2] doc: add maintainers section to the contributors guide
> -Original Message- > From: Power, Ciara > Sent: Tuesday, February 13, 2018 9:09 AM > To: dev@dpdk.org > Cc: Mcnamara, John ; Kovacevic, Marko > ; Power, Ciara > Subject: [PATCH v2] doc: add maintainers section to the contributors guide > > Add a maintainers section to the contributors guide to have a low tech > location to check/link to the current maintainers. This file is included > dynamically from the MAINTAINERS file in the root directory of the DPDK > source when the docs are built. This also allows us to link to the file > from other sections of the docs. > > Signed-off-by: Ciara Power This will be useful. Acked-by: John McNamara
Re: [dpdk-dev] [PATCH] usertools/dpdk-devbind.py: add support for wind river avp device
On 13-Feb-18 1:43 AM, Zhang, Xiaohua wrote: Hi Anatoly, AVP is a virtual NIC type, so you are right. When using the AVP device, you will see the following information from lspci (example). Slot: :00:05.0 Class: Unclassified device [00ff] Vendor: Red Hat, Inc [1af4] Device:Virtio memory balloon [1002] SVendor: Red Hat, Inc [1af4] SDevice: Device [0005] PhySlot:5 Driver:virtio-pci It is a little different with the standard "Ethernet" controller, such as "Class: Ethernet controller [0200]". Theoretically, the AVP is a memory based device. That's the reason, I put it as separate catalog. OK, fair enough. Is there any way we can make this category not-WindRiver AVP specific? Are there other similar devices out there that could potentially fit into this category? BR. Xiaohua Zhang -Original Message- Is there any particular reason why this device appears in its own category, rather than being added to one of the existing device classes? I'm not familiar with AVP but it looks like it's a NIC, so shouldn't it be in network_devices category? -- Thanks, Anatoly -- Thanks, Anatoly
[dpdk-dev] next techboard meeting 2018-02-14
Hi, The next Technical Board meeting will happen on IRC freenode #dpdk-board this wednesday 14 february 3pm UTC. You will find links to the agenda and previous meetings on this page: http://dpdk.org/dev/techboard-minutes The last one is not yet on the website: http://dpdk.org/ml/archives/dev/2018-February/090698.html Please send on any items requiring techboard attention. Thanks, Olivier
Re: [dpdk-dev] [PATCH] devtools: add script to verify map files
On 2/12/2018 4:13 PM, Pavan Nikhilesh wrote: > This script checks for the symbols specified in the map files against > the symbols present in the map file directory. > Currently, the script checks for map files in drivers and lib directory. > > Example: > ./devtools/check-map.py > > The following symbols are unused : > > Map file : /home/pavan/Work/clean/dpdk/drivers/mempool/dpaa/... > ['rte_dpaa_pool_table'] > > Map file : /home/pavan/Work/clean/dpdk/drivers/bus/fslmc/... > ['qbman_get_version', 'qbman_swp_send_multiple'] > > ... > > Signed-off-by: Pavan Nikhilesh +1 to improve our tools. Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] usertools/dpdk-devbind.py: add support for wind river avp device
On 2/13/2018 10:06 AM, Burakov, Anatoly wrote: > On 13-Feb-18 1:43 AM, Zhang, Xiaohua wrote: >> Hi Anatoly, >> AVP is a virtual NIC type, so you are right. >> >> When using the AVP device, you will see the following information from lspci >> (example). >> Slot: :00:05.0 >> Class: Unclassified device [00ff] >> Vendor: Red Hat, Inc [1af4] >> Device:Virtio memory balloon [1002] >> SVendor: Red Hat, Inc [1af4] >> SDevice: Device [0005] >> PhySlot:5 >> Driver:virtio-pci >> >> It is a little different with the standard "Ethernet" controller, such as >> "Class: Ethernet controller [0200]". >> Theoretically, the AVP is a memory based device. That's the reason, I put it >> as separate catalog. >> > > OK, fair enough. Is there any way we can make this category > not-WindRiver AVP specific? Are there other similar devices out there > that could potentially fit into this category? Can we call it "memory_devices" instead of "avp_devices" ? > >> >> BR. >> Xiaohua Zhang >> >> -Original Message- > > > >> >> Is there any particular reason why this device appears in its own category, >> rather than being added to one of the existing device classes? >> I'm not familiar with AVP but it looks like it's a NIC, so shouldn't it be >> in network_devices category? >> >> -- >> Thanks, >> Anatoly >> > >
Re: [dpdk-dev] [dpdk-stable] [PATCH] build: remove unused map symbols
On 2/13/2018 4:56 AM, Hemant Agrawal wrote: > On 2/13/2018 9:16 AM, Hemant Agrawal wrote: >> HI Pavan, >> >> On 2/12/2018 7:53 PM, Pavan Nikhilesh wrote: >>> Remove some unused map symbol. >>> >>> Signed-off-by: Pavan Nikhilesh <...> > Acked-by: Hemant Agrawal Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH v1] doc: update deprecation notice of rte_devargs
On 2/7/2018 12:41 PM, Shreyansh Jain wrote: > On Wednesday 07 February 2018 02:56 PM, Gaetan Rivet wrote: >> The declaration and identification of devices will change in v18.05. >> >> Remove the precedent deprecation notice >> >> Add new one reflecting the planned changes more accurately, >> updated for v18.05. >> >> Signed-off-by: Gaetan Rivet >> --- > > Acked-By: Shreyansh Jain Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for RSS configuration structure
On 2/13/2018 6:52 AM, Shahaf Shuler wrote: > Tuesday, February 6, 2018 9:39 AM, Xueming Li: >> Subject: [PATCH v2] doc: announce ABI change for RSS configuration >> structure >> >> Update deprecation notice for the new rss_level field of rte_eth_rss_conf. >> >> Link: http://www.dpdk.org/dev/patchwork/patch/31891 >> >> Signed-off-by: Xueming Li >> --- >> doc/guides/rel_notes/deprecation.rst | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/doc/guides/rel_notes/deprecation.rst >> b/doc/guides/rel_notes/deprecation.rst >> index d59ad5988..4bfce3bd7 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -59,3 +59,7 @@ Deprecation Notices >>be added between the producer and consumer structures. The size of the >>structure and the offset of the fields will remain the same on >>platforms with 64B cache line, but will change on other platforms. >> + >> +* ethdev: A new rss level field planned in 18.05. >> + The new API add rss_level field to ``rte_eth_rss_conf`` to enable a >> +choice >> + of RSS hash calculation on outer or inner header of tunneled packet. > > Acked-By: Shahaf Shuler Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH v2] doc: remove eal API for default mempool ops name
On 2/2/2018 2:01 PM, Olivier Matz wrote: > On Fri, Feb 02, 2018 at 02:01:42PM +0530, Hemant Agrawal wrote: >> Signed-off-by: Hemant Agrawal >> --- >> v2: fix checkpatch errors >> >> doc/guides/rel_notes/deprecation.rst | 9 + >> 1 file changed, 9 insertions(+) >> >> diff --git a/doc/guides/rel_notes/deprecation.rst >> b/doc/guides/rel_notes/deprecation.rst >> index d59ad59..c7d8f25 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -8,6 +8,15 @@ API and ABI deprecation notices are to be posted here. >> Deprecation Notices >> --- >> >> +* eal: a new set of mbuf mempool ops name APIs for user, platform and best >> + mempool names have been defined in ``rte_mbuf`` in v18.02. The uses of >> + ``rte_eal_mbuf_default_mempool_ops`` shall be replaced by >> + ``rte_mbuf_best_mempool_ops``. >> + The following function is now redundant and it is target to be deprecated >> in >> + 18.05: >> + >> + - ``rte_eal_mbuf_default_mempool_ops`` >> + >> * eal: several API and ABI changes are planned for ``rte_devargs`` in >> v18.02. >>The format of device command line parameters will change. The bus will >> need >>to be explicitly stated in the device declaration. The enum >> ``rte_devtype`` > > Acked-by: Olivier Matz Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH v2 0/3] Cryptodev API/ABI deprecation notices
> -Original Message- > From: De Lara Guarch, Pablo > Sent: Tuesday, January 30, 2018 12:14 PM > To: akhil.go...@nxp.com; hemant.agra...@nxp.com; Doherty, Declan > ; jerin.ja...@caviumnetworks.com; Trahe, > Fiona ; Griffin, John ; Jain, > Deepak K ; j...@semihalf.com; > t...@semihalf.com; d...@marvell.com; nsams...@marvell.com; > jianbo@arm.com > Cc: dev@dpdk.org; De Lara Guarch, Pablo > > Subject: [PATCH v2 0/3] Cryptodev API/ABI deprecation notices > > v2: > - Added an extra deprecation announcement > - Bonded the other two deprecation notices with the new one in a > patchset > > Pablo de Lara (3): > doc: announce ABI change for crypto info struct > doc: announce deprecation for attach/detach crypto session > doc: announce deprecation in crypto queue pair start/stop > > doc/guides/rel_notes/deprecation.rst | 15 +++ > lib/librte_cryptodev/rte_cryptodev.h | 4 > 2 files changed, 19 insertions(+) > > -- > 2.14.3 Deferring this to 18.05, so we could discuss a replacement for pci_dev structure in the cryptodev info structure, also needed for ethdev. Pablo
Re: [dpdk-dev] [dpdk-techboard] next techboard meeting 2018-02-14
13/02/2018 11:37, Olivier Matz: > Please send on any items requiring techboard attention. If some deprecation notices require some special attention, we should discuss them in the techboard meeting, just before closing the release. The most obvious deprecations will be accepted before the meeting. We can review the remaining ones.
Re: [dpdk-dev] [PATCH v3 2/2] doc: add guidelines for stable tags
On 1/16/2018 4:37 PM, Mcnamara, John wrote: > > >> -Original Message- >> From: Kovacevic, Marko >> Sent: Tuesday, January 16, 2018 9:13 AM >> To: dev@dpdk.org >> Cc: Mcnamara, John ; Yigit, Ferruh >> ; hemant.agra...@nxp.com; Kovacevic, Marko >> >> Subject: [PATCH v3 2/2] doc: add guidelines for stable tags >> >>Added contribution guideline for adding stable >>tags when sending patches all fix patches to the >>master branch that are candidates for backporting >> >> Signed-off-by: Marko Kovacevic >> Acked-by: Hemant Agrawal > > The commit message shouldn't be indented. Apart from that: > > Acked-by: John McNamara Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH v3 1/2] doc: add guidelines for coverity tags
On 1/16/2018 4:37 PM, Mcnamara, John wrote: > > >> -Original Message- >> From: Kovacevic, Marko >> Sent: Tuesday, January 16, 2018 9:13 AM >> To: dev@dpdk.org >> Cc: Mcnamara, John ; Yigit, Ferruh >> ; hemant.agra...@nxp.com; Kovacevic, Marko >> >> Subject: [PATCH v3 1/2] doc: add guidelines for coverity tags >> >> Added contribution guideline for adding tags >> when sending patches that have been raised by >> coverity >> >> Signed-off-by: Marko Kovacevic >> Acked-by: Hemant Agrawal > > The commit message shouldn't be indented. Apart from that: > > Acked-by: John McNamara Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH v3] doc: ethdev ABI change deprecation notice
On 1/12/2018 2:38 PM, Neil Horman wrote: > On Fri, Jan 12, 2018 at 10:29:46AM +, Kirill Rybalchenko wrote: >> Signed-off-by: Kirill Rybalchenko >> >> Acked-by: Marko Kovacevic >> --- >> doc/guides/rel_notes/deprecation.rst | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/doc/guides/rel_notes/deprecation.rst >> b/doc/guides/rel_notes/deprecation.rst >> index 13e8543..aaf306a 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -45,6 +45,12 @@ Deprecation Notices >>Target release for removal of the legacy API will be defined once most >>PMDs have switched to rte_flow. >> >> +* ethdev: announce ABI change >> + The size of variables flow_types_mask in rte_eth_fdir_info structure, >> + sym_hash_enable_mask and valid_bit_mask in rte_eth_hash_global_conf >> structure >> + will be increased from 32 to 64 bits to fulfill hardware requirements. >> + This change will break existing ABI as size of the structures will >> increase. >> + >> * i40e: The default flexible payload configuration which extracts the first >> 16 >>bytes of the payload for RSS will be deprecated starting from 18.02. If >>required the previous behavior can be configured using existing flow >> -- >> 2.5.5 >> >> > Acked-by: Neil Horman Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for RSS configuration structure
-Original Message- > Date: Tue, 13 Feb 2018 11:27:34 + > From: Ferruh Yigit > To: Shahaf Shuler , "Xueming(Steven) Li" > , Thomas Monjalon , Neil > Horman > CC: "dev@dpdk.org" > Subject: Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for RSS > configuration structure > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.6.0 > > On 2/13/2018 6:52 AM, Shahaf Shuler wrote: > > Tuesday, February 6, 2018 9:39 AM, Xueming Li: > >> Subject: [PATCH v2] doc: announce ABI change for RSS configuration > >> structure > >> > >> Update deprecation notice for the new rss_level field of rte_eth_rss_conf. > >> > >> Link: http://www.dpdk.org/dev/patchwork/patch/31891 > >> > >> Signed-off-by: Xueming Li > >> --- > >> doc/guides/rel_notes/deprecation.rst | 4 > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/doc/guides/rel_notes/deprecation.rst > >> b/doc/guides/rel_notes/deprecation.rst > >> index d59ad5988..4bfce3bd7 100644 > >> --- a/doc/guides/rel_notes/deprecation.rst > >> +++ b/doc/guides/rel_notes/deprecation.rst > >> @@ -59,3 +59,7 @@ Deprecation Notices > >>be added between the producer and consumer structures. The size of the > >>structure and the offset of the fields will remain the same on > >>platforms with 64B cache line, but will change on other platforms. > >> + > >> +* ethdev: A new rss level field planned in 18.05. > >> + The new API add rss_level field to ``rte_eth_rss_conf`` to enable a > >> +choice > >> + of RSS hash calculation on outer or inner header of tunneled packet. > > > > Acked-By: Shahaf Shuler > > Acked-by: Ferruh Yigit Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH v3 3/3] doc: update build-sdk-quick txt file
On 6/12/2017 1:50 PM, Mcnamara, John wrote: > > >> -Original Message- >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Hunt >> Sent: Wednesday, June 7, 2017 3:38 PM >> To: dev@dpdk.org >> Cc: tho...@monjalon.net; shreyansh.j...@nxp.com; Hunt, David >> >> Subject: [dpdk-dev] [PATCH v3 3/3] doc: update build-sdk-quick txt file >> >> * Add in information about 'make defconfig' >> * Add in information about RTE_TEMPLATE environment variable >> * Explain the default directory for 'O=' a bit better >> * Clean up text alignment >> >> Signed-off-by: David Hunt > > Acked-by: John McNamara Acked-by: Ferruh Yigit
[dpdk-dev] [PATCH] net/mlx5: revert multicast rule Verbs flow type
This is to revert the following commits:
commit da646bd93888 ("net/mlx5: fix all multi verification code position")
commit 0a40a1363a4d ("net/mlx5: fix flow type for allmulti rules")
The last one introduced a bug in the following diff:
@ -1262,6 +1274,7 @@ struct ibv_spec_header {
eth.val.ether_type &= eth.mask.ether_type;
}
mlx5_flow_create_copy(parser, ð, eth_size);
+ parser->allmulti = eth.val.dst_mac[0] & 1;
return 0;
}
As broadcast rules will be considered of type allmulti as well.
The patch was originally intended to enable VF to receive all multicast
traffic by using the IBV_FLOW_ATTR_MC_DEFAULT flow type.
Since the support was removed from the kernel there is no point with
fixing this issue, hence the revert.
Cc: nelio.laranje...@6wind.com
Cc: rasl...@mellanox.com
Cc: sta...@dpdk.org
Signed-off-by: Shahaf Shuler
---
drivers/net/mlx5/mlx5_flow.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index f88ece123..323dab723 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -391,7 +391,6 @@ static const struct mlx5_flow_items mlx5_flow_items[] = {
/** Structure to pass to the conversion function. */
struct mlx5_flow_parse {
uint32_t inner; /**< Set once VXLAN is encountered. */
- uint32_t allmulti:1; /**< Set once allmulti dst MAC is encountered. */
uint32_t create:1;
/**< Whether resources should remain after a validate. */
uint32_t drop:1; /**< Target is a drop queue. */
@@ -1128,17 +1127,6 @@ priv_flow_convert(struct priv *priv,
attr->priority +
hash_rxq_init[parser->layer].flow_priority;
}
- if (parser->allmulti &&
- parser->layer == HASH_RXQ_ETH) {
- for (i = 0; i != hash_rxq_init_n; ++i) {
- if (!parser->queue[i].ibv_attr)
- continue;
- if (parser->queue[i].ibv_attr->num_of_specs != 1)
- break;
- parser->queue[i].ibv_attr->type =
- IBV_FLOW_ATTR_MC_DEFAULT;
- }
- }
exit_free:
/* Only verification is expected, all resources should be released. */
if (!parser->create) {
@@ -1246,7 +1234,6 @@ mlx5_flow_create_eth(const struct rte_flow_item *item,
eth.val.ether_type &= eth.mask.ether_type;
}
mlx5_flow_create_copy(parser, ð, eth_size);
- parser->allmulti = eth.val.dst_mac[0] & 1;
return 0;
}
--
2.12.0
Re: [dpdk-dev] [PATCH] net/mlx5: revert multicast rule Verbs flow type
On Tue, Feb 13, 2018 at 02:31:55PM +0200, Shahaf Shuler wrote:
> This is to revert the following commits:
> commit da646bd93888 ("net/mlx5: fix all multi verification code position")
> commit 0a40a1363a4d ("net/mlx5: fix flow type for allmulti rules")
>
> The last one introduced a bug in the following diff:
> @ -1262,6 +1274,7 @@ struct ibv_spec_header {
> eth.val.ether_type &= eth.mask.ether_type;
> }
> mlx5_flow_create_copy(parser, ð, eth_size);
> + parser->allmulti = eth.val.dst_mac[0] & 1;
> return 0;
> }
>
> As broadcast rules will be considered of type allmulti as well.
>
> The patch was originally intended to enable VF to receive all multicast
> traffic by using the IBV_FLOW_ATTR_MC_DEFAULT flow type.
> Since the support was removed from the kernel there is no point with
> fixing this issue, hence the revert.
>
> Cc: nelio.laranje...@6wind.com
> Cc: rasl...@mellanox.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Shahaf Shuler
Acked-by: Nelio Laranjeiro
> ---
> drivers/net/mlx5/mlx5_flow.c | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index f88ece123..323dab723 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -391,7 +391,6 @@ static const struct mlx5_flow_items mlx5_flow_items[] = {
> /** Structure to pass to the conversion function. */
> struct mlx5_flow_parse {
> uint32_t inner; /**< Set once VXLAN is encountered. */
> - uint32_t allmulti:1; /**< Set once allmulti dst MAC is encountered. */
> uint32_t create:1;
> /**< Whether resources should remain after a validate. */
> uint32_t drop:1; /**< Target is a drop queue. */
> @@ -1128,17 +1127,6 @@ priv_flow_convert(struct priv *priv,
> attr->priority +
> hash_rxq_init[parser->layer].flow_priority;
> }
> - if (parser->allmulti &&
> - parser->layer == HASH_RXQ_ETH) {
> - for (i = 0; i != hash_rxq_init_n; ++i) {
> - if (!parser->queue[i].ibv_attr)
> - continue;
> - if (parser->queue[i].ibv_attr->num_of_specs != 1)
> - break;
> - parser->queue[i].ibv_attr->type =
> - IBV_FLOW_ATTR_MC_DEFAULT;
> - }
> - }
> exit_free:
> /* Only verification is expected, all resources should be released. */
> if (!parser->create) {
> @@ -1246,7 +1234,6 @@ mlx5_flow_create_eth(const struct rte_flow_item *item,
> eth.val.ether_type &= eth.mask.ether_type;
> }
> mlx5_flow_create_copy(parser, ð, eth_size);
> - parser->allmulti = eth.val.dst_mac[0] & 1;
> return 0;
> }
>
> --
> 2.12.0
>
--
Nélio Laranjeiro
6WIND
Re: [dpdk-dev] [PATCH] doc: announce PMD API change for set default MAC
Wednesday, January 31, 2018 9:12 PM, Ferruh Yigit: > On 1/30/2018 6:06 AM, Andrew Rybchenko wrote: > > On 01/29/2018 08:13 PM, Olivier Matz wrote: > >> Announce internal PMD API change in the function to set the default > >> MAC address. The objective is to be able to notify errors occurring > >> in the PMD. > >> > >> Link: > >> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdp > >> > dk.org%2Fdev%2Fpatchwork%2Fpatch%2F32284%2F&data=02%7C01%7Csha > hafs%40 > >> > mellanox.com%7C5a25d2b43a32440d2e5c08d568de7559%7Ca652971c7d2e4d > 9ba6a > >> > 4d149256f461b%7C0%7C0%7C636530227046083042&sdata=uMIQfiMB7pEFwi > ELWH4Z > >> gvHBpq%2FXuYDYr7B6ICB34kE%3D&reserved=0 > >> > >> Signed-off-by: Olivier Matz > >> --- > >> doc/guides/rel_notes/deprecation.rst | 8 > >> 1 file changed, 8 insertions(+) > >> > >> diff --git a/doc/guides/rel_notes/deprecation.rst > >> b/doc/guides/rel_notes/deprecation.rst > >> index 43a39d827..8ad4407c2 100644 > >> --- a/doc/guides/rel_notes/deprecation.rst > >> +++ b/doc/guides/rel_notes/deprecation.rst > >> @@ -76,3 +76,11 @@ Deprecation Notices > >> * mbuf: The mbuf flags ``PKT_TX_VLAN_PKT`` and ``PKT_TX_QINQ_PKT`` > are > >> respectively renamed as ``PKT_TX_VLAN`` and ``PKT_TX_QINQ``. The > old > >> names will be removed in v18.08. > >> + > >> +* ethdev: The prototype and the behavior of > >> + ``dev_ops->eth_mac_addr_set()`` will change in v18.05. A return > >> +code > >> + will be added to notify the caller if an error occurred in the > >> +PMD. In > >> + ``rte_eth_dev_default_mac_addr_set()``, the new default MAC > >> +address > >> + will be copied in ``dev->data->mac_addrs[0]`` only if the > >> +operation is > >> + succesfull. This modification will only impact the PMDs, not the > >> + applications. > > > > Acked-by: Andrew Rybchenko > > Acked-by: Ferruh Yigit Acked-by: Shahaf Shuler
Re: [dpdk-dev] [PATCH] doc: coding style: use linux kernel style for indentation
On 1/13/2016 4:49 PM, stephen at networkplumber.org (Stephen Hemminger) wrote: > On Wed, 13 Jan 2016 15:07:08 + > Bruce Richardson wrote: > >> So, while the two-tab indent may look "a bit weird" it does solve the two >> issues >> above. I believe practical benefits should override initial impressions. [It >> took >> me a while to get used to also, but now I very much like it as a style.] > > I don't think that deviating from kernel style for this case is justified. This is very old patch still sitting in patchwork, re-visiting it mainly to be able to clean the patchwork. This is a syntax change request and although I have my personal preferences I would be OK with whatever decided. Currently there is already a decided syntax, changing it after this point will cause either mixed usage or a big syntax cleanup patch. I think both are not good. I am for continue whatever documented in current DPDK coding style doc, hence NAK from my side. Thanks, ferruh
Re: [dpdk-dev] [PATCH] doc: coding style: use linux kernel style for indentation
On Tue, Feb 13, 2018 at 12:51:57PM +, Ferruh Yigit wrote: > On 1/13/2016 4:49 PM, stephen at networkplumber.org (Stephen Hemminger) wrote: > > On Wed, 13 Jan 2016 15:07:08 + > > Bruce Richardson wrote: > > > >> So, while the two-tab indent may look "a bit weird" it does solve the two > >> issues > >> above. I believe practical benefits should override initial impressions. > >> [It took > >> me a while to get used to also, but now I very much like it as a style.] > > > > I don't think that deviating from kernel style for this case is justified. > > This is very old patch still sitting in patchwork, re-visiting it mainly to be > able to clean the patchwork. Just drop it, there is no reason to revisit it. --yliu > > This is a syntax change request and although I have my personal preferences I > would be OK with whatever decided. > > Currently there is already a decided syntax, changing it after this point will > cause either mixed usage or a big syntax cleanup patch. I think both are not > good. > > I am for continue whatever documented in current DPDK coding style doc, hence > NAK from my side. > > Thanks, > ferruh
Re: [dpdk-dev] [PATCH] doc: announce API change for ethdev port info
On Mon, Oct 16, 2017 at 04:27:47PM +0200, Ivan Boule wrote: > To help administrative tasks on ports, new per-port information need > to be added into the data structure rte_eth_dev_info supplied by the > dev_infos_get() function exported by a Poll Mode Driver. > > See http://dpdk.org/ml/archives/dev/2017-September/074885.html for > details. > > Signed-off-by: Ivan Boule > Acked-by: Olivier Matz I didn't have the time to work on this topic for this release. Let's first wait that a new RFC is proposed, then I will resubmit a new deprecation notice if required.
Re: [dpdk-dev] [PATCH v3] doc: ethdev ABI change deprecation notice
On Tue, Feb 13, 2018 at 12:09:19PM +, Ferruh Yigit wrote: > On 1/12/2018 2:38 PM, Neil Horman wrote: > > On Fri, Jan 12, 2018 at 10:29:46AM +, Kirill Rybalchenko wrote: > >> Signed-off-by: Kirill Rybalchenko > >> > >> Acked-by: Marko Kovacevic > >> --- > >> doc/guides/rel_notes/deprecation.rst | 6 ++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/doc/guides/rel_notes/deprecation.rst > >> b/doc/guides/rel_notes/deprecation.rst > >> index 13e8543..aaf306a 100644 > >> --- a/doc/guides/rel_notes/deprecation.rst > >> +++ b/doc/guides/rel_notes/deprecation.rst > >> @@ -45,6 +45,12 @@ Deprecation Notices > >>Target release for removal of the legacy API will be defined once most > >>PMDs have switched to rte_flow. > >> > >> +* ethdev: announce ABI change > >> + The size of variables flow_types_mask in rte_eth_fdir_info structure, > >> + sym_hash_enable_mask and valid_bit_mask in rte_eth_hash_global_conf > >> structure > >> + will be increased from 32 to 64 bits to fulfill hardware requirements. > >> + This change will break existing ABI as size of the structures will > >> increase. > >> + > >> * i40e: The default flexible payload configuration which extracts the > >> first 16 > >>bytes of the payload for RSS will be deprecated starting from 18.02. If > >>required the previous behavior can be configured using existing flow > >> -- > >> 2.5.5 > >> > >> > > Acked-by: Neil Horman > > Acked-by: Ferruh Yigit Acked-by: Olivier Matz
[dpdk-dev] [PATCH] doc: fix jumbo frames entry in tap features
The current implementation of the Tap PMD doesn't support packet size
grater than 1522B, so no need to set jumbo frames in the Tap features.
Fixes: 04b2c3c94346 ("doc: add tap features")
Cc: sta...@dpdk.org
Signed-off-by: Matan Azrad
---
doc/guides/nics/features/tap.ini | 1 -
1 file changed, 1 deletion(-)
diff --git a/doc/guides/nics/features/tap.ini b/doc/guides/nics/features/tap.ini
index 8bc5187..519cad9 100644
--- a/doc/guides/nics/features/tap.ini
+++ b/doc/guides/nics/features/tap.ini
@@ -8,7 +8,6 @@ Speed capabilities = P
Link status = Y
Link status event= Y
Rx interrupt = Y
-Jumbo frame = Y
Promiscuous mode = Y
Allmulticast mode= Y
Basic stats = Y
--
1.9.5
Re: [dpdk-dev] [PATCH v7 0/3] failsafe: fix hotplug races
Hi Matan, On Mon, Feb 12, 2018 at 08:51:39PM +, Matan Azrad wrote: > This series fixes failsafe race between control commands to the asynchronic > plug-out\in processes. > Thanks for tackling this complicated issue. For the series: Acked-by: Gaetan Rivet I hope there will be more work on this matter soon. > V7(matan): > improve commit logs. > return back emty line. > return back description wrongly removed. > > V6(matan): > Full lock based fix. > Change the remove flag scope until SW resources release. > > v5(Matan): > Change defines names to failsafe convention (UNSAFE). > split a fix patch. > > v4(Matan): > Rebase on top of 18.02-rc3. > Extend the fix for other control commands. > Fix hotplug alarm cancel. > > V3(Ophir): > Rebase v2. > Add rationales (copy from an email which accompanied v2). > > > > Matan Azrad (3): > net/failsafe: fix hotplug alarm cancel > net/failsafe: fix removal scope > net/failsafe: fix hotplug races > > drivers/net/failsafe/Makefile | 1 + > drivers/net/failsafe/failsafe.c | 53 +--- > drivers/net/failsafe/failsafe_ether.c | 6 ++ > drivers/net/failsafe/failsafe_flow.c| 20 - > drivers/net/failsafe/failsafe_ops.c | 149 > ++-- > drivers/net/failsafe/failsafe_private.h | 56 > 6 files changed, 248 insertions(+), 37 deletions(-) > > -- > 1.9.5 > -- Gaëtan Rivet 6WIND
Re: [dpdk-dev] [PATCH 0/3] Some fixes on virtio-user/vhost
On 02/12/2018 04:20 AM, Jianfeng Tan wrote: Patch 1: a trivial fix on reword a log message. Patch 2: fix the rxq interrupt mode when virtio-user is used with vhost kernel. Patch 3: a trivial fix on LSC fd init when virtio-user is used with vhost kernel. Jianfeng Tan (3): net/vhost: fix incorrect log info net/virtio-user: fix not working with vhost kernel net/virtio-user: fix not proper initialized drivers/net/vhost/rte_eth_vhost.c| 4 ++-- drivers/net/virtio/virtio_user/virtio_user_dev.c | 5 + 2 files changed, 7 insertions(+), 2 deletions(-) For the series: Reviewed-by: Maxime Coquelin Thomas, I would suggest to pick this series for v18.02, as patch 2 fixes a bug introduced in this release cycle. Thanks, Maxime
Re: [dpdk-dev] [dpdk-stable] [PATCH] build: remove unused map symbols
12/02/2018 18:41, Neil Horman: > On Mon, Feb 12, 2018 at 07:53:05PM +0530, Pavan Nikhilesh wrote: > > Remove some unused map symbol. > > > > Signed-off-by: Pavan Nikhilesh > Acked-by: Neil Horman Applied, thanks
Re: [dpdk-dev] [PATCH] eal: fix rte_errno values for IPC API
> > rte_errno values should not be negative.
> >
> > Fixes: bacaa2754017 ("eal: add channel for multi-process communication")
> > Fixes: 783b6e54971d ("eal: add synchronous multi-process communication")
> > Cc: jianfeng@intel.com
> > Signed-off-by: Anatoly Burakov
>
> Reviewed-by: Jianfeng Tan
>
> Thanks for fixing this.
Applied, thanks
There are a lot of similar issues:
git grep -l 'rte_errno = -E' | sed 's,[^/]*$,,' | sort -u
drivers/event/opdl/
drivers/event/sw/
drivers/net/avf/
drivers/net/e1000/
drivers/net/ena/
drivers/net/enic/
drivers/net/fm10k/
drivers/net/i40e/
drivers/net/ixgbe/
drivers/net/qede/
drivers/net/vmxnet3/
examples/ipsec-secgw/
lib/librte_ether/
lib/librte_eventdev/
Re: [dpdk-dev] [PATCH] eal: fix rte_errno values for IPC API
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Tuesday, February 13, 2018 1:51 PM
> To: Burakov, Anatoly
> Cc: dev@dpdk.org; Tan, Jianfeng
> Subject: Re: [dpdk-dev] [PATCH] eal: fix rte_errno values for IPC API
>
> > > rte_errno values should not be negative.
> > >
> > > Fixes: bacaa2754017 ("eal: add channel for multi-process communication")
> > > Fixes: 783b6e54971d ("eal: add synchronous multi-process communication")
> > > Cc: jianfeng@intel.com
> > > Signed-off-by: Anatoly Burakov
> >
> > Reviewed-by: Jianfeng Tan
> >
> > Thanks for fixing this.
>
> Applied, thanks
>
> There are a lot of similar issues:
>
> git grep -l 'rte_errno = -E' | sed 's,[^/]*$,,' | sort -u
>
> drivers/event/opdl/
> drivers/event/sw/
> lib/librte_eventdev/
I just checked the eventdev.h port_link() docs, which indicate negative return
values.
Perhaps the header is wrong too - but the PMDs adhere to the library header in
this case.
Is there a requirement for rte_errno to be positive?
It looks to be declared as per-lcore signed int in rte_errno.h +20
Either-way, if we want to change the PMDs, we should change the Eventdev APIs,
which means API breakage, and application changes to handle changed return
values.
Sound like more work than it is worth it to me?
Re: [dpdk-dev] [PATCH] eal: fix rte_errno values for IPC API
On 13-Feb-18 2:16 PM, Van Haaren, Harry wrote:
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Tuesday, February 13, 2018 1:51 PM
To: Burakov, Anatoly
Cc: dev@dpdk.org; Tan, Jianfeng
Subject: Re: [dpdk-dev] [PATCH] eal: fix rte_errno values for IPC API
rte_errno values should not be negative.
Fixes: bacaa2754017 ("eal: add channel for multi-process communication")
Fixes: 783b6e54971d ("eal: add synchronous multi-process communication")
Cc: jianfeng@intel.com
Signed-off-by: Anatoly Burakov
Reviewed-by: Jianfeng Tan
Thanks for fixing this.
Applied, thanks
There are a lot of similar issues:
git grep -l 'rte_errno = -E' | sed 's,[^/]*$,,' | sort -u
drivers/event/opdl/
drivers/event/sw/
lib/librte_eventdev/
I just checked the eventdev.h port_link() docs, which indicate negative return
values.
Perhaps the header is wrong too - but the PMDs adhere to the library header in
this case.
Is there a requirement for rte_errno to be positive?
It looks to be declared as per-lcore signed int in rte_errno.h +20
Either-way, if we want to change the PMDs, we should change the Eventdev APIs,
which means API breakage, and application changes to handle changed return
values.
Sound like more work than it is worth it to me?
To be clear, documentation doesn't *explicitly* spell this out, so it
can be interpreted as not having an opinion on this. So i think the
first step should be fixing documentation to clearly indicate this is to
be expected at least of new code (unless decided against for consistency
reasons).
However, while docs don't state this outright, i think they imply it
both in cases of referring to errno values and returning "-errno" values
(which implies sign isn't part of the errno value). Plus, errno values
in Linux are always positive, plus rte_strerror() expects a positive
value, and (as correctly pointed out by Harry) our custom errno values -
so at least our API expects it to be positive, even if it doesn't state
it outright.
--
Thanks,
Anatoly
Re: [dpdk-dev] [dpdk-techboard] next techboard meeting 2018-02-14
On 2/13/2018 10:37 AM, Olivier Matz wrote: > Hi, > > The next Technical Board meeting will happen on IRC freenode #dpdk-board > this wednesday 14 february 3pm UTC. > > You will find links to the agenda and previous meetings on this page: > http://dpdk.org/dev/techboard-minutes > The last one is not yet on the website: > http://dpdk.org/ml/archives/dev/2018-February/090698.html > > Please send on any items requiring techboard attention. Can we discuss following process patch: https://dpdk.org/dev/patchwork/patch/33250/ Mainly the issue is how to approach a patch that effects other parts of the DPDK, who should update those dependent parts, the initiator of the feature or the maintainer of those parts? Two opposed arguments on issue: - If initiator doesn't fix the dependent code, somebody needs to follow the dependent parts to do the work, which is a maintenance cost keep growing by time. - If initiator has to do the all work, this is too much work for initiator and may prevent improvements because of too much work, or because of missing knowledge in dependent parts. Thanks, ferruh > > Thanks, > Olivier >
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On 12-Feb-18 10:00 PM, Ravi Kerur wrote: Let me just give you what has been tested and working/nonworking scenarios. Some of your questions might get answered as well. Test bed is very simple with 2 VF's created under IXGBE PF on host with one VF interface added to ovs-bridge on host and another VF interface given to guest. Test connectivity between VF's via ping. Host and guest -- Kernel 4.9 Host -- Qemu 2.11.50 (tried both released 2.11 and tip of the git (2.11.50)) DPDK -- 17.05.1 on host and guest Host and guest -- booted with GRUB intel_iommu=on (which enables IOMMU). Have tried with "iommu=on and intel_iommu=on" as well, but iommu=on is not needed when intel_iommu=on is set. Test-scenario-1: Host -- ixgbe_vf driver, Guest ixgbe_vf driver ping works Test-scenario-2: Host -- DPDK vfio-pci driver, Guest ixgbe_vf driver ping works Test-scenario-3: Host -- DPDK vfio-pci driver, Guest DPDK vfio-pci driver, DMAR errors seen on host, ping doesn't work OK, that makes it clearer, thanks. Does the third scenario work in other DPDK versions? No. Tried 16.11 same issue on guest and works fine on host. So now we've moved from "this worked on 16.11" to "this never worked". It would be good to see output of rte_dump_physmem_layout() on both host and guest, and check which address triggers the DMAR error (i.e. if the physical address is present in mappings for either DPDK process). -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH 1/1] doc: announce API change to lcore role function
On 1/12/2018 8:45 PM, Erik Gabriel Carrillo wrote: > This an API/ABI change notice for DPDK 18.05 announcing a change in > the meaning of the return values of the rte_lcore_has_role() function. > > Signed-off-by: Erik Gabriel Carrillo Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH 1/1] doc: announce API change to lcore role function
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit > Sent: Tuesday, February 13, 2018 2:38 PM > To: Carrillo, Erik G ; nhor...@tuxdriver.com > Cc: dev@dpdk.org; pbhagavat...@caviumnetworks.com; acon...@redhat.com; > tho...@monjalon.net > Subject: Re: [dpdk-dev] [PATCH 1/1] doc: announce API change to lcore role > function > > On 1/12/2018 8:45 PM, Erik Gabriel Carrillo wrote: > > This an API/ABI change notice for DPDK 18.05 announcing a change in > > the meaning of the return values of the rte_lcore_has_role() function. > > > > Signed-off-by: Erik Gabriel Carrillo > > Acked-by: Ferruh Yigit Ah yes, lets make the return be 1 if the correct RTE_ROLE is probed - makes sense. @Pavan, as original author of code, do you have an Ack for this? :) Acked-by: Harry van Haaren
Re: [dpdk-dev] [PATCH 1/1] doc: announce API change to lcore role function
On Tue, Feb 13, 2018 at 02:43:39PM +, Van Haaren, Harry wrote: > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit > > Sent: Tuesday, February 13, 2018 2:38 PM > > To: Carrillo, Erik G ; nhor...@tuxdriver.com > > Cc: dev@dpdk.org; pbhagavat...@caviumnetworks.com; acon...@redhat.com; > > tho...@monjalon.net > > Subject: Re: [dpdk-dev] [PATCH 1/1] doc: announce API change to lcore role > > function > > > > On 1/12/2018 8:45 PM, Erik Gabriel Carrillo wrote: > > > This an API/ABI change notice for DPDK 18.05 announcing a change in > > > the meaning of the return values of the rte_lcore_has_role() function. > > > > > > Signed-off-by: Erik Gabriel Carrillo > > > > Acked-by: Ferruh Yigit > > > Ah yes, lets make the return be 1 if the correct RTE_ROLE is probed - makes > sense. > > @Pavan, as original author of code, do you have an Ack for this? :) > > > Acked-by: Harry van Haaren Acked-by: Pavan Nikhilesh
Re: [dpdk-dev] [RFC v3, 1/3] cryptodev: set private data for session-less mode
Hi,
> -Original Message-
> From: Gujjar, Abhinandan S
> Sent: Thursday, February 1, 2018 9:30 AM
> To: Doherty, Declan ; akhil.go...@nxp.com; De
> Lara Guarch, Pablo ;
> jerin.jacobkollanukka...@cavium.com
> Cc: dev@dpdk.org; Vangati, Narender ;
> Gujjar, Abhinandan S ; Rao, Nikhil
>
> Subject: [RFC v3, 1/3] cryptodev: set private data for session-less mode
>
> The application may want to store private data along with the
> rte_crypto_op that is transparent to the rte_cryptodev layer.
> For e.g., If an eventdev based application is submitting a crypto session-less
> operation and wants to indicate event information required to construct a
> new event that will be enqueued to eventdev after completion of the crypto
> operation. This patch provides a mechanism for the application to associate
> this information with the rte_crypto_op in session-less mode.
>
> Signed-off-by: Abhinandan Gujjar
> Signed-off-by: Nikhil Rao
> ---
> Notes:
> V3:
> 1. Added separate patch for session-less private data
> 2. Added more information on offset
> V2:
> 1. Removed enum rte_crypto_op_private_data_type
> 2. Corrected formatting
>
> lib/librte_cryptodev/rte_crypto.h | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_cryptodev/rte_crypto.h
> b/lib/librte_cryptodev/rte_crypto.h
> index 95cf861..2540426 100644
> --- a/lib/librte_cryptodev/rte_crypto.h
> +++ b/lib/librte_cryptodev/rte_crypto.h
> @@ -84,8 +84,14 @@ struct rte_crypto_op {
>*/
> uint8_t sess_type;
> /**< operation session type */
> + uint16_t private_data_offset;
> + /**< Offset to indicate start of private data (if any). The offset
> + * is counted from the start of the rte_crypto_op including IV.
I assume that if this offset is 0, it means that there is no private data?
Also, I would reword the Doxygen comment a bit (here is my suggestion, which
looks a bit long, but I hope it is descriptive).
" Offset to indicate start of private data (if any). The offset is counted from
the start of the rte_crypto_op structure.
The private data may be used by the application to store information which
should remain untouched in the library/driver.
Note that an Initialization Vector (IV) for the operation may be placed at the
end of the structure as well, so caution to avoid overwrites has to be taken."
> + * The private data may be used by the application to store
> + * information which should remain untouched in the library/driver
> + */
>
> - uint8_t reserved[5];
> + uint8_t reserved[3];
> /**< Reserved bytes to fill 64 bits for future additions */
> struct rte_mempool *mempool;
> /**< crypto operation mempool which operation is allocated from
> */
> --
> 1.9.1
Apart from the comments above, this overall looks good to me.
I would say you could submit a v1 with some implementation.
Could you also modify the Cryptodev section in the Programmer's Guide document,
to reflect these changes?
Thanks,
Pablo
Re: [dpdk-dev] [RFC v3, 2/3] cryptodev: add support to set session private data
Hi, > -Original Message- > From: Gujjar, Abhinandan S > Sent: Thursday, February 1, 2018 9:30 AM > To: Doherty, Declan ; akhil.go...@nxp.com; De > Lara Guarch, Pablo ; > jerin.jacobkollanukka...@cavium.com > Cc: dev@dpdk.org; Vangati, Narender ; > Gujjar, Abhinandan S ; Rao, Nikhil > > Subject: [RFC v3, 2/3] cryptodev: add support to set session private data > > The application may want to store private data along with the > rte_cryptodev that is transparent to the rte_cryptodev layer. > For e.g., If an eventdev based application is submitting a > rte_cryptodev_sym_session operation and wants to indicate event > information required to construct a new event that will be enqueued to > eventdev after completion of the rte_cryptodev_sym_session operation. > This patch provides a mechanism for the application to associate this > information with the rte_cryptodev_sym_session session. > The application can set the private data using > rte_cryptodev_sym_session_set_private_data() and retrieve it using > rte_cryptodev_sym_session_get_private_data(). > > Signed-off-by: Abhinandan Gujjar > Signed-off-by: Nikhil Rao This looks good to me. I am expecting then a v1 with the implementation of these functions. Thanks, Pablo
Re: [dpdk-dev] [PATCH] doc: fix jumbo frames entry in tap features
Acked-by: Pascal Mazon
On 13/02/2018 14:22, Matan Azrad wrote:
> The current implementation of the Tap PMD doesn't support packet size
> grater than 1522B, so no need to set jumbo frames in the Tap features.
>
> Fixes: 04b2c3c94346 ("doc: add tap features")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Matan Azrad
> ---
> doc/guides/nics/features/tap.ini | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/doc/guides/nics/features/tap.ini
> b/doc/guides/nics/features/tap.ini
> index 8bc5187..519cad9 100644
> --- a/doc/guides/nics/features/tap.ini
> +++ b/doc/guides/nics/features/tap.ini
> @@ -8,7 +8,6 @@ Speed capabilities = P
> Link status = Y
> Link status event= Y
> Rx interrupt = Y
> -Jumbo frame = Y
> Promiscuous mode = Y
> Allmulticast mode= Y
> Basic stats = Y
[dpdk-dev] [PATCH] ethdev: adjust error log level
DPDK API does not propagate the reason of device allocation failure
from rte_eth_dev_allocate() up to the DPDK application (e.g. Open
vSwitch).
Log level of associated log entries was changed to warning. So user
can find additional details in log files also in production systems,
where debug messages cannot be turned on.
Signed-off-by: Martin Klozik
---
lib/librte_ether/rte_ethdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a6ce2a5..0590f0c 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -277,12 +277,12 @@ rte_eth_dev_allocate(const char *name)
port_id = rte_eth_dev_find_free_port();
if (port_id == RTE_MAX_ETHPORTS) {
- RTE_PMD_DEBUG_TRACE("Reached maximum number of Ethernet
ports\n");
+ RTE_LOG(ERR, EAL, "Reached maximum number of Ethernet ports\n");
goto unlock;
}
if (rte_eth_dev_allocated(name) != NULL) {
- RTE_PMD_DEBUG_TRACE("Ethernet Device with name %s already
allocated!\n",
+ RTE_LOG(ERR, EAL, "Ethernet Device with name %s already
allocated!\n",
name);
goto unlock;
}
--
2.7.4
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
[dpdk-dev] [PATCH] examples/performance-thread: updates hasan alayli's license
This updates hasan alayli's license to be the standard BSD-3-Clause license used for the rest of DPDK,bringing the files in compliance with the DPDK licensing policy. Signed-off-by: Lee Daly --- .../performance-thread/common/arch/x86/stack.h | 40 -- 1 file changed, 7 insertions(+), 33 deletions(-) diff --git a/examples/performance-thread/common/arch/x86/stack.h b/examples/performance-thread/common/arch/x86/stack.h index edf21c0..ee78ba2 100644 --- a/examples/performance-thread/common/arch/x86/stack.h +++ b/examples/performance-thread/common/arch/x86/stack.h @@ -1,37 +1,11 @@ -/* SPDX-License-Identifier: BSD-3-Clause - * Copyright(c) 2015 Intel Corporation. - * Copyright(c) Cavium, Inc. 2017. - * All rights reserved. - */ - -/* - * Some portions of this software is derived from the - * https://github.com/halayli/lthread which carrys the following license. - * +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2015 Intel Corporation. + * Copyright(c) Cavium, Inc. 2017. + * All rights reserved * Copyright (C) 2012, Hasan Alayli - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - *notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - *notice, this list of conditions and the following disclaimer in the - *documentation and/or other materials provided with the distribution. - * - * THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - */ - + * Portions derived from: https://github.com/halayli/lthread + * With permissions from Hasan Alayli to use them as BSD-3-Clause +*/ #ifndef STACK_H #define STACK_H -- 2.7.4
Re: [dpdk-dev] [PATCH] examples: update copyrights and license
Feel free to relicense lthread to BSD-3. On Thu, Feb 8, 2018 at 8:55 PM, Hemant Agrawal wrote: > On 2/8/2018 7:18 PM, Daly, Lee wrote: > >> Subject: Re: [PATCH] examples: update copyrights and license >>> >>> Hi Lee, >>> Hasan Alayli's license seems to be BSD-2-Clause, which is >>> typically >>> compatible with BSD-3-Clause. >>> It will be ideal to get ACK from Hasan Alayli to re-license it >>> as BSD-3- >>> clause and change it to SPDX tag. >>> >> >> >> Agree. This should be done for 18.05 release, >> This patch set it just updating the BSD-3 licenses. >> >> Yes, this patch need to wait. > > You can not put a "SPDX-License-Identifier: BSD-3-Clause" on a mixed > licensed file. > > > Regards, > Hemant > >
Re: [dpdk-dev] [PATCH v3] ethdev: fix ethdev data alignment
12/02/2018 14:13, Jerin Jacob:
> The struct rte_eth_dev_data is used in ethdev fastpath routines
> and it not aligned to cache line size. This patch fixes the ethdev
> data alignment.
>
> The alignment was broken from the "first public release" changeset
> where ethdev data address was aligned only to the first port.
> Remaining ports alignment was defined by the size of the struct
> (rte_eth_dev_data). This scheme is not guaranteed to be cache line
> aligned all the time.
>
> "ethdev: add port ownership" change set introduced a
> rte_eth_dev_shared_data container for port ownership change,
> This resulted in rte_eth_dev->data memory for the first port also
> as cache unaligned.
>
> Added a compiler alignment attribute to make sure
> rte_eth_dev->data always cache aligned so that CPU/compiler
> 1) Avoid sharing the element with another cache line
> 2) Can load/store the elements in struct rte_eth_dev_data as
> naturally aligned.
>
> Some platform like thunderX could see performance regression of 1%
> at "ethdev: add port ownership" change set with
> 1 port/1 queue l3fwd application and this patch fixes that regression.
>
> example command:
> sudo ./examples/l3fwd/build/l3fwd -c 0xff00 -- -p 0x1 --config="(0,0,9)"
>
> Fixes: af75078fece3 ("first public release")
> Fixes: 5b7ba31148a8 ("ethdev: add port ownership")
>
> Cc: sta...@dpdk.org
>
> Cc: Matan Azrad
> Cc: Thomas Monjalon
> Cc: Konstantin Ananyev
>
> Signed-off-by: Jerin Jacob
> Signed-off-by: Pavan Nikhilesh
> ---
Acked-by: Thomas Monjalon
Applied, thanks
Re: [dpdk-dev] [PATCH] ethdev: adjust error log level
13/02/2018 16:03, Martin Klozik: > DPDK API does not propagate the reason of device allocation failure > from rte_eth_dev_allocate() up to the DPDK application (e.g. Open > vSwitch). > Log level of associated log entries was changed to warning. So user > can find additional details in log files also in production systems, > where debug messages cannot be turned on. > > Signed-off-by: Martin Klozik Acked-by: Thomas Monjalon Applied, thanks
Re: [dpdk-dev] [PATCH] net/dpaa2: remove unused global variable
> > Fixes: a5fc38d422a7 ("net/dpaa2: support Rx packet parsing")
> >
> > Cc: hemant.agra...@nxp.com
> > Signed-off-by: Jerin Jacob
> > ---
> > drivers/net/dpaa2/base/dpaa2_hw_dpni_annot.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Acked-by: Hemant Agrawal
Applied, thanks
Re: [dpdk-dev] [PATCH] eal: fix rte_errno values for IPC API
On Tue, Feb 13, 2018 at 02:16:08PM +, Van Haaren, Harry wrote:
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Tuesday, February 13, 2018 1:51 PM
> > To: Burakov, Anatoly
> > Cc: dev@dpdk.org; Tan, Jianfeng
> > Subject: Re: [dpdk-dev] [PATCH] eal: fix rte_errno values for IPC API
> >
> > > > rte_errno values should not be negative.
> > > >
> > > > Fixes: bacaa2754017 ("eal: add channel for multi-process communication")
> > > > Fixes: 783b6e54971d ("eal: add synchronous multi-process communication")
> > > > Cc: jianfeng@intel.com
> > > > Signed-off-by: Anatoly Burakov
> > >
> > > Reviewed-by: Jianfeng Tan
> > >
> > > Thanks for fixing this.
> >
> > Applied, thanks
> >
> > There are a lot of similar issues:
> >
> > git grep -l 'rte_errno = -E' | sed 's,[^/]*$,,' | sort -u
> >
> > drivers/event/opdl/
> > drivers/event/sw/
>
> > lib/librte_eventdev/
>
>
> I just checked the eventdev.h port_link() docs, which indicate negative
> return values.
> Perhaps the header is wrong too - but the PMDs adhere to the library header
> in this case.
>
> Is there a requirement for rte_errno to be positive?
> It looks to be declared as per-lcore signed int in rte_errno.h +20
>
I think I wrote that part of the documentation, and it never crossed my
mind that people would set rte_errno to negative values, given how
errno from system calls are always positive. However, I think this
omission should be rectified, and we should enforce having rte_errno
values as positive.
> Either-way, if we want to change the PMDs, we should change the Eventdev APIs,
> which means API breakage, and application changes to handle changed return
> values.
>
> Sound like more work than it is worth it to me?
I would view it as restoring sanity (or balance to the force if you
prefer! :-) ), so I'd definitely be ok with an ABI break to do that.
/Bruce
Re: [dpdk-dev] [PATCH] examples/performance-thread: updates hasan alayli's license
> -Original Message- > From: Lee Daly [mailto:lee.d...@intel.com] > Subject: [PATCH] examples/performance-thread: updates hasan alayli's license > Importance: High > > This updates hasan alayli's license to be the standard BSD-3-Clause license > used > for the rest of DPDK,bringing the files in compliance with the DPDK licensing > policy. > > Signed-off-by: Lee Daly > --- > .../performance-thread/common/arch/x86/stack.h | 40 > -- > 1 file changed, 7 insertions(+), 33 deletions(-) Acked-by: Hemant Agrawal > > diff --git a/examples/performance-thread/common/arch/x86/stack.h > b/examples/performance-thread/common/arch/x86/stack.h > index edf21c0..ee78ba2 100644 > --- a/examples/performance-thread/common/arch/x86/stack.h > +++ b/examples/performance-thread/common/arch/x86/stack.h > @@ -1,37 +1,11 @@ > -/* SPDX-License-Identifier: BSD-3-Clause > - * Copyright(c) 2015 Intel Corporation. > - * Copyright(c) Cavium, Inc. 2017. > - * All rights reserved. > - */
Re: [dpdk-dev] [PATCH] net/mlx5: fix socket assertion error during dev close
06/02/2018 14:22, Nélio Laranjeiro:
> On Tue, Feb 06, 2018 at 08:54:22PM +0800, Xueming Li wrote:
> > This patch fixed primary socket assertion error during close on a device
> > that failed to start.
> >
> > Fixes: f8b9a3bad467 ("net/mlx5: install a socket to exchange a file
> > descriptor")
> > Signed-off-by: Xueming Li
>
> Acked-by: Nelio Laranjeiro
Applied, thanks
Re: [dpdk-dev] [PATCH] examples/performance-thread: updates hasan alayli's license
On 2/13/2018 3:45 PM, Hemant Agrawal wrote: > >> -Original Message- >> From: Lee Daly [mailto:lee.d...@intel.com] >> Subject: [PATCH] examples/performance-thread: updates hasan alayli's license >> Importance: High >> >> This updates hasan alayli's license to be the standard BSD-3-Clause license >> used >> for the rest of DPDK,bringing the files in compliance with the DPDK licensing >> policy. >> >> Signed-off-by: Lee Daly >> --- >> .../performance-thread/common/arch/x86/stack.h | 40 >> -- >> 1 file changed, 7 insertions(+), 33 deletions(-) > > Acked-by: Hemant Agrawal Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] net/mlx5: revert multicast rule Verbs flow type
13/02/2018 13:41, Nélio Laranjeiro:
> On Tue, Feb 13, 2018 at 02:31:55PM +0200, Shahaf Shuler wrote:
> > This is to revert the following commits:
> > commit da646bd93888 ("net/mlx5: fix all multi verification code position")
> > commit 0a40a1363a4d ("net/mlx5: fix flow type for allmulti rules")
> >
> > The last one introduced a bug in the following diff:
> > @ -1262,6 +1274,7 @@ struct ibv_spec_header {
> > eth.val.ether_type &= eth.mask.ether_type;
> > }
> > mlx5_flow_create_copy(parser, ð, eth_size);
> > + parser->allmulti = eth.val.dst_mac[0] & 1;
> > return 0;
> > }
> >
> > As broadcast rules will be considered of type allmulti as well.
> >
> > The patch was originally intended to enable VF to receive all multicast
> > traffic by using the IBV_FLOW_ATTR_MC_DEFAULT flow type.
> > Since the support was removed from the kernel there is no point with
> > fixing this issue, hence the revert.
> >
> > Cc: nelio.laranje...@6wind.com
> > Cc: rasl...@mellanox.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Shahaf Shuler
>
> Acked-by: Nelio Laranjeiro
Applied, thanks
Re: [dpdk-dev] [RFC v3, 1/3] cryptodev: set private data for session-less mode
Hi Pablo,
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, February 13, 2018 8:24 PM
> To: Gujjar, Abhinandan S ; Doherty, Declan
> ; akhil.go...@nxp.com;
> jerin.jacobkollanukka...@cavium.com
> Cc: dev@dpdk.org; Vangati, Narender ; Rao,
> Nikhil
> Subject: RE: [RFC v3, 1/3] cryptodev: set private data for session-less mode
>
> Hi,
>
> > -Original Message-
> > From: Gujjar, Abhinandan S
> > Sent: Thursday, February 1, 2018 9:30 AM
> > To: Doherty, Declan ; akhil.go...@nxp.com;
> > De Lara Guarch, Pablo ;
> > jerin.jacobkollanukka...@cavium.com
> > Cc: dev@dpdk.org; Vangati, Narender ;
> > Gujjar, Abhinandan S ; Rao, Nikhil
> >
> > Subject: [RFC v3, 1/3] cryptodev: set private data for session-less
> > mode
> >
> > The application may want to store private data along with the
> > rte_crypto_op that is transparent to the rte_cryptodev layer.
> > For e.g., If an eventdev based application is submitting a crypto
> > session-less operation and wants to indicate event information
> > required to construct a new event that will be enqueued to eventdev
> > after completion of the crypto operation. This patch provides a
> > mechanism for the application to associate this information with the
> rte_crypto_op in session-less mode.
> >
> > Signed-off-by: Abhinandan Gujjar
> > Signed-off-by: Nikhil Rao
> > ---
> > Notes:
> > V3:
> > 1. Added separate patch for session-less private data
> > 2. Added more information on offset
> > V2:
> > 1. Removed enum rte_crypto_op_private_data_type
> > 2. Corrected formatting
> >
> > lib/librte_cryptodev/rte_crypto.h | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_cryptodev/rte_crypto.h
> > b/lib/librte_cryptodev/rte_crypto.h
> > index 95cf861..2540426 100644
> > --- a/lib/librte_cryptodev/rte_crypto.h
> > +++ b/lib/librte_cryptodev/rte_crypto.h
> > @@ -84,8 +84,14 @@ struct rte_crypto_op {
> > */
> > uint8_t sess_type;
> > /**< operation session type */
> > + uint16_t private_data_offset;
> > + /**< Offset to indicate start of private data (if any). The offset
> > +* is counted from the start of the rte_crypto_op including IV.
>
> I assume that if this offset is 0, it means that there is no private data?
Yes
>
> Also, I would reword the Doxygen comment a bit (here is my suggestion, which
> looks a bit long, but I hope it is descriptive).
>
> " Offset to indicate start of private data (if any). The offset is counted
> from the
> start of the rte_crypto_op structure.
> The private data may be used by the application to store information which
> should remain untouched in the library/driver.
> Note that an Initialization Vector (IV) for the operation may be placed at
> the end
> of the structure as well, so caution to avoid overwrites has to be taken."
>
>
> > +* The private data may be used by the application to store
> > +* information which should remain untouched in the library/driver
> > +*/
> >
> > - uint8_t reserved[5];
> > + uint8_t reserved[3];
> > /**< Reserved bytes to fill 64 bits for future additions */
> > struct rte_mempool *mempool;
> > /**< crypto operation mempool which operation is allocated from */
> > --
> > 1.9.1
>
> Apart from the comments above, this overall looks good to me.
> I would say you could submit a v1 with some implementation.
Ok.
> Could you also modify the Cryptodev section in the Programmer's Guide
> document, to reflect these changes?
Sure.
Thanks
Abhinandan
>
> Thanks,
> Pablo
Re: [dpdk-dev] [RFC v3, 2/3] cryptodev: add support to set session private data
Hi Pablo, > -Original Message- > From: De Lara Guarch, Pablo > Sent: Tuesday, February 13, 2018 8:27 PM > To: Gujjar, Abhinandan S ; Doherty, Declan > ; akhil.go...@nxp.com; > jerin.jacobkollanukka...@cavium.com > Cc: dev@dpdk.org; Vangati, Narender ; Rao, > Nikhil > Subject: RE: [RFC v3, 2/3] cryptodev: add support to set session private data > > Hi, > > > -Original Message- > > From: Gujjar, Abhinandan S > > Sent: Thursday, February 1, 2018 9:30 AM > > To: Doherty, Declan ; akhil.go...@nxp.com; > > De Lara Guarch, Pablo ; > > jerin.jacobkollanukka...@cavium.com > > Cc: dev@dpdk.org; Vangati, Narender ; > > Gujjar, Abhinandan S ; Rao, Nikhil > > > > Subject: [RFC v3, 2/3] cryptodev: add support to set session private > > data > > > > The application may want to store private data along with the > > rte_cryptodev that is transparent to the rte_cryptodev layer. > > For e.g., If an eventdev based application is submitting a > > rte_cryptodev_sym_session operation and wants to indicate event > > information required to construct a new event that will be enqueued to > > eventdev after completion of the rte_cryptodev_sym_session operation. > > This patch provides a mechanism for the application to associate this > > information with the rte_cryptodev_sym_session session. > > The application can set the private data using > > rte_cryptodev_sym_session_set_private_data() and retrieve it using > > rte_cryptodev_sym_session_get_private_data(). > > > > Signed-off-by: Abhinandan Gujjar > > Signed-off-by: Nikhil Rao > > This looks good to me. I am expecting then a v1 with the implementation of > these functions. Sure. I will post the implementation. Thanks Abhinandan > > Thanks, > Pablo
Re: [dpdk-dev] [PATCH v7 0/3] failsafe: fix hotplug races
13/02/2018 14:31, Gaëtan Rivet: > Hi Matan, > > On Mon, Feb 12, 2018 at 08:51:39PM +, Matan Azrad wrote: > > This series fixes failsafe race between control commands to the asynchronic > > plug-out\in processes. > > > > Thanks for tackling this complicated issue. > For the series: > > Acked-by: Gaetan Rivet Applied, thanks
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/failsafe: fix reconfiguration
12/02/2018 19:42, Gaëtan Rivet:
> Hi Matan,
>
> On Sun, Feb 11, 2018 at 05:27:34PM +, Matan Azrad wrote:
> > Fail-safe PMD manages the states of its sub-devices gradually:
> > DEV_UNDEFINED, DEV_PARSED, DEV_PROBED, DEV_ACTIVE, DEV_STARTED.
> >
> > When the sub-device arguments successfully was parsed, the state is
> > raised from DEV_UNDEFINED to DEV_PARSED.
> > When the sub-device successfully was probed, the state is raised from
> > DEV_PARSED to DEV_PROBED.
> > When the sub-device successfully was configured by
> > rte_eth_dev_configure(), the state is raised from DEV_PROBED to
> > DEV_ACTIVE.
> > When the sub-device successfully was started by rte_eth_dev_start(), the
> > state is raised from DEV_ACTIVE to DEV_STARTED.
> >
> > When the sub-device successfully was stopped by rte_eth_dev_stop(), the
> > state is degraded from DEV_STARTED to DEV_ACTIVE.
> > When the sub-device successfully was closed by rte_eth_dev_close(), the
> > state is degraded from DEV_ACTIVE to DEV_PROBED.
> > When the sub-device successfully was removed by
> > rte_eal_hotplug_remove(), the state is degraded from DEV_PROBED to
> > DEV_UNDEFINED.
> >
> > Fail-safe dev_configure() operation calls to its sub-devices
> > dev_configure() operation, but only for sub-devices which are in
> > DEV_PROBED state, means that sub-devices which are in DEV_ACTIVE state
> > because the application triggered dev_stop() operation cannot be
> > reconfigured again by dev_configure() operation which is really
> > problematic when application wants to reconfigure its ports.
> > Actually, the application may get success report when some of the
> > sub-devices are not in the wanted configuration.
> >
> > The current behavior of fail-safe dev_configure() is correct only for
> > the first time dev_configure() is triggered by the application or for
> > sub-device synchronization in plug-in event, but it ignores the option
> > for reconfiguration from application side.
> >
> > Allow calling to sub-devices dev_configure() operations also in
> > DEV_ACTIVE state when the call was triggered by the application.
> >
> > Fixes: a46f8d584eb8 ("net/failsafe: add fail-safe PMD")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Matan Azrad
>
> The commit log is too verbose, but otherwise the issue is real and the
> fix correct.
>
> Acked-by: Gaetan Rivet
Applied, thanks
Re: [dpdk-dev] [PATCH v2] net/tap: add CRC stripping capability
13/02/2018 09:14, Ophir Munk:
> CRC stripping is executed in the kernel outside of TAP PMD scope.
> There is no prevention that the TAP PMD will report on Rx CRC
> stripping capability.
> In the corrupted code, TAP PMD did not report on this capability.
> The fix enables TAP PMD to report that Rx CRC stripping is supported.
>
> Fixes: 02f96a0a82d1 ("net/tap: add TUN/TAP device PMD")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ophir Munk
Applied, thanks
Re: [dpdk-dev] [PATCH] doc: fix jumbo frames entry in tap features
> > The current implementation of the Tap PMD doesn't support packet size
> > grater than 1522B, so no need to set jumbo frames in the Tap features.
> >
> > Fixes: 04b2c3c94346 ("doc: add tap features")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Matan Azrad
> Acked-by: Pascal Mazon
Applied, thanks
Re: [dpdk-dev] [PATCH] net/nfp: rename nfp PF file
12/02/2018 10:57, Alejandro Lucero: > Other NICs with VF support do not use the _pf suffix for these files > but just for the VF description. > > This change makes NFP files consistent in this regard and helps with > how the DPDK web nics features matrix shows NFP devices. > > Signed-off-by: Alejandro Lucero Applied, thanks
Re: [dpdk-dev] [PATCH] doc: add missing SFN8xxx adapters to the list of supported
> > Signed-off-by: Andrew Rybchenko > > Acked-by: John McNamara Applied, thanks
Re: [dpdk-dev] [PATCH v2] doc: update doc for intel VF usage
> > update for intel VF usage: > > - Add note for AVF device ID generation. > > - Add steps for vfio-pci pass through. > > > > Signed-off-by: Jingjing Wu > > Acked-by: John McNamara Applied, thanks
[dpdk-dev] [PATCH v2] example exception_path: cache align per CPU stats
Align stats structure to cache line to prevent bouncing per CPU stats
structure between cache lines.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Dustin Lundquist
---
v2:
* Include fixes tag
Verified alignment of lcore_stats array elements using gdb.
examples/exception_path/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/exception_path/main.c b/examples/exception_path/main.c
index 280a50451..3e5b1e718 100644
--- a/examples/exception_path/main.c
+++ b/examples/exception_path/main.c
@@ -108,7 +108,7 @@ struct stats {
uint64_t rx;
uint64_t tx;
uint64_t dropped;
-};
+} __rte_cache_aligned;
/* Array of lcore-specific stats */
static struct stats lcore_stats[RTE_MAX_LCORE];
--
2.11.0
Re: [dpdk-dev] [RFC] tunnel endpoint hw acceleration enablement
Hi,
Apologies for being late to this thread, I've read the ensuing discussion
(hope I didn't miss any) and also think rte_flow could be improved in
several ways to enable TEP support, in particular regarding the ordering of
actions.
On the other hand I'm not sure a dedicated API for TEP is needed at all. I'm
not convinced rte_security chose the right path and would like to avoid
repeating the same mistakes if possible, more below.
On Thu, Dec 21, 2017 at 10:21:13PM +, Doherty, Declan wrote:
> This RFC contains a proposal to add a new tunnel endpoint API to DPDK that
> when used
> in conjunction with rte_flow enables the configuration of inline data path
> encapsulation
> and decapsulation of tunnel endpoint network overlays on accelerated IO
> devices.
>
> The proposed new API would provide for the creation, destruction, and
> monitoring of a tunnel endpoint in supporting hw, as well as capabilities
> APIs to allow the
> acceleration features to be discovered by applications.
>
> /** Tunnel Endpoint context, opaque structure */
> struct rte_tep;
>
> enum rte_tep_type {
>RTE_TEP_TYPE_VXLAN = 1, /**< VXLAN Protocol */
>RTE_TEP_TYPE_NVGRE, /**< NVGRE Protocol */
>...
> };
>
> /** Tunnel Endpoint Attributes */
> struct rte_tep_attr {
>enum rte_type_type type;
>
>/* other endpoint attributes here */
> }
>
> /**
> * Create a tunnel end-point context as specified by the flow attribute and
> pattern
> *
> * @param port_id Port identifier of Ethernet device.
> * @param attrFlow rule attributes.
> * @param pattern Pattern specification by list of rte_flow_items.
> * @return
> * - On success returns pointer to TEP context
> * - On failure returns NULL
> */
> struct rte_tep *rte_tep_create(uint16_t port_id,
> struct rte_tep_attr *attr, struct rte_flow_item
> pattern[])
>
> /**
> * Destroy an existing tunnel end-point context. All the end-points context
> * will be destroyed, so all active flows using tep should be freed before
> * destroying context.
> * @param port_idPort identifier of Ethernet device.
> * @param tepTunnel endpoint context
> * @return
> * - On success returns 0
> * - On failure returns 1
> */
> int rte_tep_destroy(uint16_t port_id, struct rte_tep *tep)
>
> /**
> * Get tunnel endpoint statistics
> *
> * @param port_idPort identifier of Ethernet device.
> * @param tepTunnel endpoint context
> * @param stats Tunnel endpoint statistics
> *
> * @return
> * - On success returns 0
> * - On failure returns 1
> */
> Int
> rte_tep_stats_get(uint16_t port_id, struct rte_tep *tep,
> struct rte_tep_stats *stats)
>
> /**
> * Get ports tunnel endpoint capabilities
> *
> * @param port_idPort identifier of Ethernet device.
> * @param capabilitiesTunnel endpoint capabilities
> *
> * @return
> * - On success returns 0
> * - On failure returns 1
> */
> int
> rte_tep_capabilities_get(uint16_t port_id,
> struct rte_tep_capabilities *capabilities)
>
>
> To direct traffic flows to hw terminated tunnel endpoint the rte_flow API is
> enhanced to add a new flow item type. This contains a pointer to the
> TEP context as well as the overlay flow id to which the traffic flow is
> associated.
>
> struct rte_flow_item_tep {
>struct rte_tep *tep;
>uint32_t flow_id;
> }
What I dislike is rte_flow item/actions relying on externally-generated
opaque objects when these can be avoided, as it means yet another API
applications have to deal with and PMDs need to implement; this adds a layer
of inefficiency in my opinion.
I believe TEP can be fully implemented through a combination of new rte_flow
pattern items/actions without involving external API calls. More on that
later.
> Also 2 new generic actions types are added encapsulation and decapsulation.
>
> RTE_FLOW_ACTION_TYPE_ENCAP
> RTE_FLOW_ACTION_TYPE_DECAP
>
> struct rte_flow_action_encap {
>struct rte_flow_item *item;
> }
>
> struct rte_flow_action_decap {
>struct rte_flow_item *item;
> }
Encap/decap actions are definitely needed and useful, no question about
that. I'm unsure about doing so through a generic action with the described
structures instead of dedicated ones though.
These can't work with anything other than rte_flow_item_tep; a special
pattern item using some kind of opaque object is needed (e.g. using
rte_flow_item_tcp makes no sense with them).
Also struct rte_flow_item is tailored for flow rule patterns, using it with
actions is not only confusing, it makes its "mask" and "last" members
useless and inconsistent with their documentation.
Although I'm not convinced an opaque object is the right approach, if we
choose this route I suggest the much simpler:
struct rte_flow_action_tep_(encap|decap) {
struct rte_tep *
Re: [dpdk-dev] [PATCH] net/mlx5: dump flow create error message
> > > > Add error message dump when flow create error happened. > > > > > > > > Signed-off-by: Xueming Li > > Acked-by: Nelio Laranjeiro Applied, thanks
[dpdk-dev] [PATCH v1] net/tap: fix promiscuous rules double insersions
Signed-off-by: Ophir Munk
---
Full Commit message will follow immediately in v2
drivers/net/tap/tap_flow.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/tap/tap_flow.c b/drivers/net/tap/tap_flow.c
index 65657f0..d1f4a52 100644
--- a/drivers/net/tap/tap_flow.c
+++ b/drivers/net/tap/tap_flow.c
@@ -123,6 +123,7 @@ enum key_status_e {
};
#define ISOLATE_HANDLE 1
+#define REMOTE_PROMISCUOUS_HANDLE 2
struct rte_flow {
LIST_ENTRY(rte_flow) next; /* Pointer to the next rte_flow structure */
@@ -1692,9 +1693,15 @@ int tap_flow_implicit_create(struct pmd_internals *pmd,
* The ISOLATE rule is always present and must have a static handle, as
* the action is changed whether the feature is enabled (DROP) or
* disabled (PASSTHRU).
+* There is just one REMOTE_PROMISCUOUS rule in all cases. It should
+* have a static handle such that adding it twice will fail with EEXIST
+* with any kernel version. Remark: old kernels may falsely accept the
+* same REMOTE_PREMISCUOUS rules if they had different handles.
*/
if (idx == TAP_ISOLATE)
remote_flow->msg.t.tcm_handle = ISOLATE_HANDLE;
+ else if (idx == TAP_REMOTE_PROMISC)
+ remote_flow->msg.t.tcm_handle = REMOTE_PROMISCUOUS_HANDLE;
else
tap_flow_set_handle(remote_flow);
if (priv_flow_process(pmd, attr, items, actions, NULL,
@@ -1709,12 +1716,16 @@ int tap_flow_implicit_create(struct pmd_internals *pmd,
}
err = tap_nl_recv_ack(pmd->nlsk_fd);
if (err < 0) {
+ /* Silently ignore re-entering remote promiscuous rule */
+ if (errno == EEXIST && idx == TAP_REMOTE_PROMISC)
+ goto success;
RTE_LOG(ERR, PMD,
"Kernel refused TC filter rule creation (%d): %s\n",
errno, strerror(errno));
goto fail;
}
LIST_INSERT_HEAD(&pmd->implicit_flows, remote_flow, next);
+success:
return 0;
fail:
if (remote_flow)
--
2.7.4
Re: [dpdk-dev] [dpdk-stable] [PATCH v2 0/3] Vhost & Virtio fixes for v18.02
12/02/2018 16:46, Maxime Coquelin: > The second revision of this series includes Olivier's patch as first > patch in order to ease Thomas job when applying. > > Patch 2 rewords the commit message with detailed informations > provided by Tiwei and olivier (Thanks!). It also moves call to > virtio_rxq_vec_setup() and removes virtqueue_enqueue_recv_refill_simple() > as no more used. > > Maxime Coquelin (2): > virtio: fix resuming port with rx vector path > vhost: don't take access_lock on VHOST_USER_RESET_OWNER > > Olivier Matz (1): > net/virtio: fix mbuf data offset for simple Rx function Applied, thanks
Re: [dpdk-dev] [PATCH 0/3] Some fixes on virtio-user/vhost
13/02/2018 14:32, Maxime Coquelin: > > On 02/12/2018 04:20 AM, Jianfeng Tan wrote: > > Patch 1: a trivial fix on reword a log message. > > Patch 2: fix the rxq interrupt mode when virtio-user is used > > with vhost kernel. > > Patch 3: a trivial fix on LSC fd init when virtio-user is used > > with vhost kernel. > > > > Jianfeng Tan (3): > >net/vhost: fix incorrect log info > >net/virtio-user: fix not working with vhost kernel > >net/virtio-user: fix not proper initialized > > For the series: > Reviewed-by: Maxime Coquelin > > Thomas, I would suggest to pick this series for v18.02, as patch 2 fixes > a bug introduced in this release cycle. Applied with these reworded titles: net/vhost: fix log messages on create/destroy net/virtio-user: fix start with kernel vhost net/virtio-user: fix interrupts with kernel vhost
Re: [dpdk-dev] [PATCH v2] example exception_path: cache align per CPU stats
13/02/2018 17:58, Dustin Lundquist:
> Align stats structure to cache line to prevent bouncing per CPU stats
> structure between cache lines.
>
> Fixes: af75078fece3 ("first public release")
>
> Signed-off-by: Dustin Lundquist
Acked-by: Remy Horton
Applied, thanks
Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: print correct crypto name
12/02/2018 08:02, Anoob Joseph:
>
> On 09/02/18 16:10, Radu Nicolau wrote:
> > When AES-256 was used aes-128 was printed in the console
> >
> > Fixes: fa9088849e12 ("examples/ipsec-secgw: support AES 256")
> > Signed-off-by: Radu Nicolau
> Acked-by: Anoob Joseph
Applied, thanks
[dpdk-dev] [PATCH v2] net/tap: fix promiscuous rules double insersions
Running testpmd command "port stop all" followed by command "port start
all" may result in a TAP error:
PMD: Kernel refused TC filter rule creation (17): File exists
Root cause analysis: during the execution of "port start all" command
testpmd calls rte_eth_promiscuous_enable() while during the execution
of "port stop all" command testpmd does not call
rte_eth_promiscuous_enable().
As a result the TAP PMD is trying to add tc (traffic control command)
promiscuous rules to the remote netvsc device consecutively. From the
kernel point of view it is seen as an attempt to add the same rule more
than once. In recent kernels (e.g. version 4.13) this attempt is rejected
with a "File exists" error. In less recent kernels (e.g. version 4.4) the
same rule may have been accepted twice successfully, which is undesirable.
In the corrupted code every tc promiscuous rule included a different
handle number parameter. If instead an identical handle number parameter is
used for all tc promiscuous rules - all kernels will reject the second
rule with a "File exists" error, which is easy to identify and to silently
ignore.
Fixes: 2bc06869cd94 ("net/tap: add remote netdevice traffic capture")
Cc: sta...@dpdk.org
Signed-off-by: Ophir Munk
---
v2: add detailed commit message
drivers/net/tap/tap_flow.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/tap/tap_flow.c b/drivers/net/tap/tap_flow.c
index 65657f0..d1f4a52 100644
--- a/drivers/net/tap/tap_flow.c
+++ b/drivers/net/tap/tap_flow.c
@@ -123,6 +123,7 @@ enum key_status_e {
};
#define ISOLATE_HANDLE 1
+#define REMOTE_PROMISCUOUS_HANDLE 2
struct rte_flow {
LIST_ENTRY(rte_flow) next; /* Pointer to the next rte_flow structure */
@@ -1692,9 +1693,15 @@ int tap_flow_implicit_create(struct pmd_internals *pmd,
* The ISOLATE rule is always present and must have a static handle, as
* the action is changed whether the feature is enabled (DROP) or
* disabled (PASSTHRU).
+* There is just one REMOTE_PROMISCUOUS rule in all cases. It should
+* have a static handle such that adding it twice will fail with EEXIST
+* with any kernel version. Remark: old kernels may falsely accept the
+* same REMOTE_PREMISCUOUS rules if they had different handles.
*/
if (idx == TAP_ISOLATE)
remote_flow->msg.t.tcm_handle = ISOLATE_HANDLE;
+ else if (idx == TAP_REMOTE_PROMISC)
+ remote_flow->msg.t.tcm_handle = REMOTE_PROMISCUOUS_HANDLE;
else
tap_flow_set_handle(remote_flow);
if (priv_flow_process(pmd, attr, items, actions, NULL,
@@ -1709,12 +1716,16 @@ int tap_flow_implicit_create(struct pmd_internals *pmd,
}
err = tap_nl_recv_ack(pmd->nlsk_fd);
if (err < 0) {
+ /* Silently ignore re-entering remote promiscuous rule */
+ if (errno == EEXIST && idx == TAP_REMOTE_PROMISC)
+ goto success;
RTE_LOG(ERR, PMD,
"Kernel refused TC filter rule creation (%d): %s\n",
errno, strerror(errno));
goto fail;
}
LIST_INSERT_HEAD(&pmd->implicit_flows, remote_flow, next);
+success:
return 0;
fail:
if (remote_flow)
--
2.7.4
[dpdk-dev] release/acquire memory barriers and ring
Hi. I've been wondering should I use a release/acquire memory barrier pair in order to be sure that the other thread will see the fully/corrected initialized object passed to it via a dpdk ring or ring itself is a kind of barrier? Let's say I have a pseudo code: Thread1: obj = alloc(); ... obj initialization ... ??? fence(memory_order_release); ??? rte_ring_sp_enqueue(ring, obj) Thread2: ??? fence(memory_order_acquire); ??? rte_ring_sc_dequeue(ring, obj) Should I use fences in that code? Thanks. -- Alex
Re: [dpdk-dev] release/acquire memory barriers and ring
I am sorry. I should've posted to the user list of couse. My mistake. 2018-02-13 22:37 GMT+03:00 Alex Kiselev : > Hi. > > I've been wondering should I use a release/acquire memory barrier pair > in order to be sure that the other thread will see the fully/corrected > initialized object > passed to it via a dpdk ring or ring itself is a kind of barrier? > > Let's say I have a pseudo code: > > Thread1: > obj = alloc(); > ... > obj initialization > ... > > ??? fence(memory_order_release); ??? > rte_ring_sp_enqueue(ring, obj) > > > Thread2: > ??? fence(memory_order_acquire); ??? > rte_ring_sc_dequeue(ring, obj) > > Should I use fences in that code? > > Thanks. > > -- > Alex
Re: [dpdk-dev] [PATCH v7 0/3] failsafe: fix hotplug races
Hi,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Tuesday, February 13, 2018 4:12 PM
> To: Matan Azrad
> Cc: dev@dpdk.org; Gaëtan Rivet
> Subject: Re: [dpdk-dev] [PATCH v7 0/3] failsafe: fix hotplug races
>
> 13/02/2018 14:31, Gaëtan Rivet:
> > Hi Matan,
> >
> > On Mon, Feb 12, 2018 at 08:51:39PM +, Matan Azrad wrote:
> > > This series fixes failsafe race between control commands to the
> asynchronic plug-out\in processes.
> > >
> >
> > Thanks for tackling this complicated issue.
> > For the series:
> >
> > Acked-by: Gaetan Rivet
>
> Applied, thanks
There is a compilation error due to this patch on FreeBSD:
drivers/net/failsafe/failsafe_private.h:377:53: error: format specifies
type 'unsigned long' but the argument has type 'pthread_t' (aka 'struct pthread
*') [-Werror,-Wformat]
DEBUG("Hot-plug mutex was locked by thread %lu%s", pthread_self(),
I am not sure how to print a pthread_t, so I can just report the issue.
Thanks,
Pablo
[dpdk-dev] 32-bit compilation & debug logs
Hi all, There is a very common pattern with build failures in DPDK. When compiling in 32-bit mode, there are some mismatches between printf format "%lu" / "%lx" and the size of the data being 64-bit. In 32-bit mode, a long is 32 bits long :) That's why "%lx" must be replaced by "%" PRIx64. long -> %lx uint64_t -> %PRIx64 Most of the times, using %l is wrong (except when printing a long). So next time you write %l, please think "I am probably wrong". For the existing codebase, please grep "%l". There are probably some remaining wrong "%l" which are not detected when compiling, because the code is in debug functions never enabled. Note that debug code should be tested but there can be some forgotten code paths. Thanks
Re: [dpdk-dev] [PATCH v7 0/3] failsafe: fix hotplug races
From: De Lara Guarch, Pablo [mailto:pablo.de.lara.gua...@intel.com]
> Hi,
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Tuesday, February 13, 2018 4:12 PM
> > To: Matan Azrad
> > Cc: dev@dpdk.org; Gaëtan Rivet
> > Subject: Re: [dpdk-dev] [PATCH v7 0/3] failsafe: fix hotplug races
> >
> > 13/02/2018 14:31, Gaëtan Rivet:
> > > Hi Matan,
> > >
> > > On Mon, Feb 12, 2018 at 08:51:39PM +, Matan Azrad wrote:
> > > > This series fixes failsafe race between control commands to the
> > asynchronic plug-out\in processes.
> > > >
> > >
> > > Thanks for tackling this complicated issue.
> > > For the series:
> > >
> > > Acked-by: Gaetan Rivet
> >
> > Applied, thanks
>
> There is a compilation error due to this patch on FreeBSD:
>
> drivers/net/failsafe/failsafe_private.h:377:53: error: format specifies type
> 'unsigned long' but the argument has type 'pthread_t' (aka 'struct pthread *')
> [-Werror,-Wformat]
> DEBUG("Hot-plug mutex was locked by thread %lu%s", pthread_self(),
>
>
> I am not sure how to print a pthread_t, so I can just report the issue.
>
Can you check with (unsigned long int) conversion?
> Thanks,
> Pablo
Re: [dpdk-dev] [PATCH v7 0/3] failsafe: fix hotplug races
13/02/2018 22:13, Matan Azrad:
> From: De Lara Guarch, Pablo [mailto:pablo.de.lara.gua...@intel.com]
> > There is a compilation error due to this patch on FreeBSD:
> >
> > drivers/net/failsafe/failsafe_private.h:377:53: error: format specifies type
> > 'unsigned long' but the argument has type 'pthread_t' (aka 'struct pthread
> > *')
> > [-Werror,-Wformat]
> > DEBUG("Hot-plug mutex was locked by thread %lu%s", pthread_self(),
> >
> >
> > I am not sure how to print a pthread_t, so I can just report the issue.
> >
> Can you check with (unsigned long int) conversion?
On FreeBSD, pthread_t is:
typedef struct pthread *pthread_t;
pthread_t is not portable and should not be printed.
I am preparing a patch to enable pthread_t debugging only in Linux.
[dpdk-dev] [PATCH] net/failsafe: fix FreeBSD build
The type pthread_t is not portable because it is freely defined.
On Linux, it is an unsigned long int which can be printed with %l.
The debug printing of the thread id is restricted to Linux only.
Fixes: 655fcd68c7d2 ("net/failsafe: fix hotplug races")
Signed-off-by: Thomas Monjalon
---
drivers/net/failsafe/failsafe_private.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/failsafe/failsafe_private.h
b/drivers/net/failsafe/failsafe_private.h
index 5b84db905..86ade029f 100644
--- a/drivers/net/failsafe/failsafe_private.h
+++ b/drivers/net/failsafe/failsafe_private.h
@@ -374,8 +374,10 @@ fs_lock(struct rte_eth_dev *dev, unsigned int is_alarm)
return ret;
}
}
+#ifdef RTE_EXEC_ENV_LINUXAPP
DEBUG("Hot-plug mutex was locked by thread %lu%s", pthread_self(),
PRIV(dev)->alarm_lock ? " by the hot-plug alarm" : "");
+#endif
return ret;
}
@@ -387,7 +389,6 @@ static inline void
fs_unlock(struct rte_eth_dev *dev, unsigned int is_alarm)
{
int ret;
- unsigned int prev_alarm_lock = PRIV(dev)->alarm_lock;
if (is_alarm) {
RTE_ASSERT(PRIV(dev)->alarm_lock == 1);
@@ -396,10 +397,14 @@ fs_unlock(struct rte_eth_dev *dev, unsigned int is_alarm)
ret = pthread_mutex_unlock(&PRIV(dev)->hotplug_mutex);
if (ret)
ERROR("Cannot unlock hot-plug mutex(%s)", strerror(ret));
- else
+#ifdef RTE_EXEC_ENV_LINUXAPP
+ else {
+ unsigned int prev_alarm_lock = PRIV(dev)->alarm_lock;
DEBUG("Hot-plug mutex was unlocked by thread %lu%s",
pthread_self(),
prev_alarm_lock ? " by the hot-plug alarm" : "");
+ }
+#endif
}
/*
--
2.15.1
Re: [dpdk-dev] [PATCH] net/failsafe: fix FreeBSD build
13/02/2018 22:33, Thomas Monjalon:
> The type pthread_t is not portable because it is freely defined.
> On Linux, it is an unsigned long int which can be printed with %l.
Forgot to add:
On FreeBSD, it is a pointer.
That's why there was this error:
drivers/net/failsafe/failsafe_private.h:377:53: error:
format specifies type 'unsigned long' but the argument has
type 'pthread_t' (aka 'struct pthread *')
Reported-by: Pablo de Lara
>
> The debug printing of the thread id is restricted to Linux only.
>
> Fixes: 655fcd68c7d2 ("net/failsafe: fix hotplug races")
>
> Signed-off-by: Thomas Monjalon
[dpdk-dev] [PATCH v2] net/failsafe: fix FreeBSD build
The type pthread_t is not portable because it is freely defined.
On Linux, it is an unsigned long int which can be printed with %l.
On FreeBSD, it is a pointer which can be printed with %p.
That's why there was this error:
drivers/net/failsafe/failsafe_private.h:377:53: error:
format specifies type 'unsigned long' but the argument has
type 'pthread_t' (aka 'struct pthread *')
Fixes: 655fcd68c7d2 ("net/failsafe: fix hotplug races")
Reported-by: Pablo de Lara
Signed-off-by: Thomas Monjalon
---
v2: adapt printing to BSD and Linux
---
drivers/net/failsafe/failsafe_private.h | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/failsafe/failsafe_private.h
b/drivers/net/failsafe/failsafe_private.h
index 5b84db905..2d16ba4ca 100644
--- a/drivers/net/failsafe/failsafe_private.h
+++ b/drivers/net/failsafe/failsafe_private.h
@@ -318,6 +318,14 @@ extern int mac_from_arg;
&((struct txq *)((s)->fs_dev->data->tx_queues[i]))->refcnt[(s)->sid] \
)
+#ifdef RTE_EXEC_ENV_BSDAPP
+#define FS_THREADID_TYPE void*
+#define FS_THREADID_FMT "p"
+#else
+#define FS_THREADID_TYPE unsigned long
+#define FS_THREADID_FMT "lu"
+#endif
+
#define LOG__(level, m, ...) \
RTE_LOG(level, PMD, "net_failsafe: " m "%c", __VA_ARGS__)
#define LOG_(level, ...) LOG__(level, __VA_ARGS__, '\n')
@@ -374,7 +382,8 @@ fs_lock(struct rte_eth_dev *dev, unsigned int is_alarm)
return ret;
}
}
- DEBUG("Hot-plug mutex was locked by thread %lu%s", pthread_self(),
+ DEBUG("Hot-plug mutex was locked by thread %" FS_THREADID_FMT "%s",
+ (FS_THREADID_TYPE)pthread_self(),
PRIV(dev)->alarm_lock ? " by the hot-plug alarm" : "");
return ret;
}
@@ -397,8 +406,8 @@ fs_unlock(struct rte_eth_dev *dev, unsigned int is_alarm)
if (ret)
ERROR("Cannot unlock hot-plug mutex(%s)", strerror(ret));
else
- DEBUG("Hot-plug mutex was unlocked by thread %lu%s",
- pthread_self(),
+ DEBUG("Hot-plug mutex was unlocked by thread %" FS_THREADID_FMT
"%s",
+ (FS_THREADID_TYPE)pthread_self(),
prev_alarm_lock ? " by the hot-plug alarm" : "");
}
--
2.15.1
Re: [dpdk-dev] [PATCH v2] net/failsafe: fix FreeBSD build
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Tuesday, February 13, 2018 10:13 PM
> To: ma...@mellanox.com
> Cc: dev@dpdk.org; gaetan.ri...@6wind.com
> Subject: [dpdk-dev] [PATCH v2] net/failsafe: fix FreeBSD build
>
> The type pthread_t is not portable because it is freely defined.
> On Linux, it is an unsigned long int which can be printed with %l.
> On FreeBSD, it is a pointer which can be printed with %p.
>
> That's why there was this error:
> drivers/net/failsafe/failsafe_private.h:377:53: error:
> format specifies type 'unsigned long' but the argument has
> type 'pthread_t' (aka 'struct pthread *')
>
> Fixes: 655fcd68c7d2 ("net/failsafe: fix hotplug races")
>
> Reported-by: Pablo de Lara
> Signed-off-by: Thomas Monjalon
Tested-by: Pablo de Lara
Re: [dpdk-dev] [PATCH] examples/performance-thread: updates hasan alayli's license
13/02/2018 17:03, Ferruh Yigit: > On 2/13/2018 3:45 PM, Hemant Agrawal wrote: > > From: Lee Daly [mailto:lee.d...@intel.com] > >> > >> This updates hasan alayli's license to be the standard BSD-3-Clause > >> license used > >> for the rest of DPDK,bringing the files in compliance with the DPDK > >> licensing > >> policy. > >> > >> Signed-off-by: Lee Daly > > > > Acked-by: Hemant Agrawal > > Acked-by: Ferruh Yigit Applied, thanks
Re: [dpdk-dev] [PATCH v2] net/failsafe: fix FreeBSD build
> -Original Message-
> From: De Lara Guarch, Pablo [mailto:pablo.de.lara.gua...@intel.com]
> Sent: Wednesday, February 14, 2018 12:19 AM
> To: Thomas Monjalon ; Matan Azrad
>
> Cc: dev@dpdk.org; gaetan.ri...@6wind.com
> Subject: RE: [dpdk-dev] [PATCH v2] net/failsafe: fix FreeBSD build
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Tuesday, February 13, 2018 10:13 PM
> > To: ma...@mellanox.com
> > Cc: dev@dpdk.org; gaetan.ri...@6wind.com
> > Subject: [dpdk-dev] [PATCH v2] net/failsafe: fix FreeBSD build
> >
> > The type pthread_t is not portable because it is freely defined.
> > On Linux, it is an unsigned long int which can be printed with %l.
> > On FreeBSD, it is a pointer which can be printed with %p.
> >
> > That's why there was this error:
> > drivers/net/failsafe/failsafe_private.h:377:53: error:
> > format specifies type 'unsigned long' but the argument has
> > type 'pthread_t' (aka 'struct pthread *')
> >
> > Fixes: 655fcd68c7d2 ("net/failsafe: fix hotplug races")
> >
> > Reported-by: Pablo de Lara
> > Signed-off-by: Thomas Monjalon
>
> Tested-by: Pablo de Lara
>
Acked-by: Matan Azrad
Re: [dpdk-dev] [PATCH v2] net/failsafe: fix FreeBSD build
> > > The type pthread_t is not portable because it is freely defined.
> > > On Linux, it is an unsigned long int which can be printed with %l.
> > > On FreeBSD, it is a pointer which can be printed with %p.
> > >
> > > That's why there was this error:
> > > drivers/net/failsafe/failsafe_private.h:377:53: error:
> > > format specifies type 'unsigned long' but the argument has
> > > type 'pthread_t' (aka 'struct pthread *')
> > >
> > > Fixes: 655fcd68c7d2 ("net/failsafe: fix hotplug races")
> > >
> > > Reported-by: Pablo de Lara
> > > Signed-off-by: Thomas Monjalon
> >
> > Tested-by: Pablo de Lara
> >
> Acked-by: Matan Azrad
Applied
Re: [dpdk-dev] [PATCH] examples/cmdline: update copyright and license
12/02/2018 11:16, Olivier Matz: > On Wed, Feb 07, 2018 at 04:15:01PM +, Ferruh Yigit wrote: > > On 1/23/2018 4:43 PM, Lee Daly wrote: > > > This updates the license on files in examples to be the standard > > > BSD-3-Clause license used for the rest of DPDK, > > > bringing the files in compliance with the DPDK licensing policy. > > > > > > Signed-off-by: Lee Daly > > > > Acked-by: Ferruh Yigit > > Acked-by: Olivier Matz Applied, thanks
Re: [dpdk-dev] [PATCH v4] examples/ip_pipeline: update copyright and license
12/02/2018 11:15, Olivier Matz: > On Wed, Feb 07, 2018 at 04:43:59PM +, Lee Daly wrote: > > This updates the Intel and Oliver Matz licenses on a file in examples > > to be the standard BSD-3-Clause license used for the rest of DPDK, > > bringing the files in compliance with the DPDK licensing policy. > > > > Signed-off-by: Lee Daly > > > > Acked-by: Ferruh Yigit > > Acked-by: Olivier Matz Applied, thanks
[dpdk-dev] Accessing 2nd cacheline in rte_pktmbuf_prefree_seg()
Hi Olivier
I'm wondering why rte_pktmbuf_prefree_seg() checks m->next instead of
m->nb_segs? As 'next' is in the 2nd cacheline, checking nb_segs seems beneficial
to the cases where almost mbufs have single segment.
A customer reported high rate of cache misses in the code and I thought the
following patch could be helpful. I haven't had them try it yet but just wanted
to hear from you.
I'd appreciate if you can review this idea.
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 62740254d..96edbcb9e 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -1398,7 +1398,7 @@ rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
if (RTE_MBUF_INDIRECT(m))
rte_pktmbuf_detach(m);
- if (m->next != NULL) {
+ if (m->nb_segs > 1) {
m->next = NULL;
m->nb_segs = 1;
}
@@ -1410,7 +1410,7 @@ rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
if (RTE_MBUF_INDIRECT(m))
rte_pktmbuf_detach(m);
- if (m->next != NULL) {
+ if (m->nb_segs > 1) {
m->next = NULL;
m->nb_segs = 1;
}
Thanks,
Yongseok
[dpdk-dev] [PATCH] net/bonding: fix link properties with autoneg
From: Chas Williams
If a link is carrier down and using autonegotiation, then the PMD may not
have detected a speed yet. In this case the best we can do is ignore the
link speed and duplex since they aren't valid. To be completely correct,
there should be additional checks to prevent a slave that negotiates a
different speed from being activated.
Signed-off-by: Chas Williams
---
drivers/net/bonding/rte_eth_bond_pmd.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 92ad688..5559879 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1545,9 +1545,10 @@ link_properties_valid(struct rte_eth_dev *ethdev,
if (bond_ctx->mode == BONDING_MODE_8023AD) {
struct rte_eth_link *bond_link = &bond_ctx->mode4.slave_link;
- if (bond_link->link_duplex != slave_link->link_duplex ||
- bond_link->link_autoneg != slave_link->link_autoneg ||
- bond_link->link_speed != slave_link->link_speed)
+ if (bond_link->link_autoneg != slave_link->link_autoneg ||
+ (bond_link->link_autoneg != ETH_LINK_AUTONEG &&
+(bond_link->link_duplex != slave_link->link_duplex ||
+ bond_link->link_speed != slave_link->link_speed)))
return -1;
}
--
2.9.5
[dpdk-dev] [PATCH] net/ixgbe: update data->eth_link status on start
From: "Charles (Chas) Williams"
dev->data->eth_link isn't updated until the first interrupt. If a
link is carrier down, then this interrupt may never happen. Before we
finished starting the PMD, call ixgbe_dev_link_update() to ensure we
have a valid status.
Signed-off-by: Chas Williams
---
drivers/net/ixgbe/ixgbe_ethdev.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 37eb668..27d29dc 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2666,6 +2666,8 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
if (err)
goto error;
+ ixgbe_dev_link_update(dev, 0);
+
skip_link_setup:
if (rte_intr_allow_others(intr_handle)) {
@@ -5033,6 +5035,8 @@ ixgbevf_dev_start(struct rte_eth_dev *dev)
ixgbevf_dev_rxtx_start(dev);
+ ixgbevf_dev_link_update(dev, 0);
+
/* check and configure queue intr-vector mapping */
if (rte_intr_cap_multiple(intr_handle) &&
dev->data->dev_conf.intr_conf.rxq) {
--
2.9.5
Re: [dpdk-dev] [PATCH v5] checkpatches.sh: Add checks for ABI symbol addition
Hi,
I wanted to push this patch in 18.02, but when looking more closely,
I see few things to improve.
As it is a tool, there is no harm to wait one more week and push it
early in 18.05.
09/02/2018 16:21, Neil Horman:
> check () { #
> + local reta
> total=$(($total + 1))
> ! $verbose || printf '\n### %s\n\n' "$3"
> if [ -n "$1" ] ; then
> @@ -96,9 +100,26 @@ check () { #
> else
> report=$($DPDK_CHECKPATCH_PATH $options - 2>/dev/null)
> fi
> - [ $? -ne 0 ] || return 0
You are removing the return, so the report will be always printed.
You must print the report only in case of error.
> + reta=$?
> +
> $verbose || printf '\n### %s\n\n' "$3"
> printf '%s\n' "$report" | sed -n '1,/^total:.*lines checked$/p'
> +
> + ! $verbose || echo
> + ! $verbose || echo "Checking API additions/removals:"
You can use printf to combine these lines.
> +
> + if [ -n "$1" ] ; then
> + report=$($VALIDATE_NEW_API $1)
Beware of spaces in file names: use quoted "$1".
> + elif [ -n "$2" ] ; then
> + report=$(git format-patch \
> + --find-renames --no-stat --stdout -1 $commit |
> + $VALIDATE_NEW_API -)
> + else
> + report=$($VALIDATE_NEW_API -)
So your script supports "-" for stdin? Nice
> + fi
> + [ $? -ne 0 -o $reta -ne 0 ] || return 0
Suggestion of more explicit variable naming:
$reta -> style_result
$? -> symbol_result
> + printf '%s\n' "$report" | sed -n '1,/^total:.*lines checked$/p'
Wrong copy/paste: the sed is useless for the API report.
[dpdk-dev] [PATCH] net/failsafe: fix Rx interrupt reinstallation
Fail-safe dev_start() operation can be called by both the application
and the hot-plug alarm mechanism.
The installation of Rx interrupt are triggered from dev_start() in any
time it is called while actually the Rx interrupt should be installed
only by the application calls.
So, each plug-in event causes reinstallation which causes memory leak.
Trigger the Rx interrupt installation only for application calls.
Fixes: 9e0360aebf23 ("net/failsafe: register as Rx interrupt mode")
Signed-off-by: Matan Azrad
---
drivers/net/failsafe/failsafe_ops.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/failsafe/failsafe_ops.c
b/drivers/net/failsafe/failsafe_ops.c
index 057e435..bbbd335 100644
--- a/drivers/net/failsafe/failsafe_ops.c
+++ b/drivers/net/failsafe/failsafe_ops.c
@@ -181,10 +181,12 @@
int ret;
fs_lock(dev, 0);
- ret = failsafe_rx_intr_install(dev);
- if (ret) {
- fs_unlock(dev, 0);
- return ret;
+ if (PRIV(dev)->alarm_lock == 0) {
+ ret = failsafe_rx_intr_install(dev);
+ if (ret) {
+ fs_unlock(dev, 0);
+ return ret;
+ }
}
FOREACH_SUBDEV(sdev, i, dev) {
if (sdev->state != DEV_ACTIVE)
--
1.9.5
Re: [dpdk-dev] [PATCH] net/bonding: fix link properties with autoneg
13/02/2018 23:54, Chas Williams: > From: Chas Williams > > If a link is carrier down and using autonegotiation, then the PMD may not > have detected a speed yet. In this case the best we can do is ignore the > link speed and duplex since they aren't valid. To be completely correct, > there should be additional checks to prevent a slave that negotiates a > different speed from being activated. > > Signed-off-by: Chas Williams Please add Fixes line to all your fix patches. Thanks
