Re: [dpdk-dev] [PATCH] crypto/dpaa2_sec: reduce init log prints
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Hemant Agrawal > Sent: Monday, July 24, 2017 8:32 AM > To: dev@dpdk.org > Cc: Shreyansh Jain > Subject: [dpdk-dev] [PATCH] crypto/dpaa2_sec: reduce init log prints > > From: Shreyansh Jain > > Signed-off-by: Shreyansh Jain Applied to dpdk-next-crypto. Thanks, Pablo
Re: [dpdk-dev] [PATCH] crypto/openssl: fix typo
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, July 25, 2017 10:07 AM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo
> Subject: [PATCH] crypto/openssl: fix typo
>
> Fixes: b79e4c00af0e ("cryptodev: use AES-GCM/CCM as AEAD algorithms")
>
> Signed-off-by: Pablo de Lara
Applied to dpdk-next-crypto.
Pablo
Re: [dpdk-dev] [PATCH] doc: support new ZUC library version
> -Original Message- > From: De Lara Guarch, Pablo > Sent: Tuesday, July 25, 2017 8:17 AM > To: dev@dpdk.org > Cc: De Lara Guarch, Pablo > Subject: [PATCH] doc: support new ZUC library version > > A new version of the LibSSO ZUC library has been released. > This version includes shared library support and bug fixes. > > This commit extends the instructions to install and initialize the PMD with > the new library, enabling also the PMD to be compiled as a shared library. > > Signed-off-by: Pablo de Lara Applied to dpdk-next-crypto. Pablo
[dpdk-dev] [PATCH] net/i40e: fix dereferencing null pointer
Add check if o_vlan_mask and i_vlan_mask are
not a NULL pointer.
Coverity issue: 143448
Coverity issue: 143449
Fixes: d37705068ee8 ("net/i40e: parse QinQ pattern")
Cc: sta...@dpdk.org
Signed-off-by: Kuba Kozak
---
drivers/net/i40e/i40e_flow.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c
index 95af701..b92719a 100644
--- a/drivers/net/i40e/i40e_flow.c
+++ b/drivers/net/i40e/i40e_flow.c
@@ -3719,8 +3719,10 @@ i40e_flow_parse_qinq_pattern(__rte_unused struct
rte_eth_dev *dev,
}
/* Get filter specification */
- if ((o_vlan_mask->tci == rte_cpu_to_be_16(I40E_TCI_MASK)) &&
- (i_vlan_mask->tci == rte_cpu_to_be_16(I40E_TCI_MASK))) {
+ if ((o_vlan_mask != NULL) && (o_vlan_mask->tci ==
+ rte_cpu_to_be_16(I40E_TCI_MASK)) &&
+ (i_vlan_mask != NULL) &&
+ (i_vlan_mask->tci == rte_cpu_to_be_16(I40E_TCI_MASK))) {
filter->outer_vlan = rte_be_to_cpu_16(o_vlan_spec->tci)
& I40E_TCI_MASK;
filter->inner_vlan = rte_be_to_cpu_16(i_vlan_spec->tci)
--
2.7.4
Re: [dpdk-dev] [PATCH] crypto/dpaa2_sec: add check for gcc toolchain
HI Akhil, > -Original Message- > From: Akhil Goyal [mailto:akhil.go...@nxp.com] > Sent: Wednesday, July 26, 2017 12:28 PM > To: dev@dpdk.org > Cc: De Lara Guarch, Pablo ; > hemant.agra...@nxp.com; Akhil Goyal > Subject: [PATCH] crypto/dpaa2_sec: add check for gcc toolchain > > Signed-off-by: Akhil Goyal I think you need to include a fixes line here, and CC stable, as this is a fix. Thanks, Pablo
Re: [dpdk-dev] [PATCH] cryptodev: fix crypto op bulk alloc Doxygen
Hi Pablo,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, July 26, 2017 5:27 AM
> To: Doherty, Declan
> Cc: dev@dpdk.org; De Lara Guarch, Pablo ;
> sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] cryptodev: fix crypto op bulk alloc Doxygen
>
> When calling rte_crypto_op_bulk_alloc, the function may
> return either a 0, if not enough objects are available
> in the mempool or the number of operations requested,
> it there are enough available. However, the Doxygen comments
> were not matching these two cases.
>
> Fixes: c0f87eb5252b ("cryptodev: change burst API to be crypto op oriented")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Pablo de Lara
> ---
> lib/librte_cryptodev/rte_crypto.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_cryptodev/rte_crypto.h
> b/lib/librte_cryptodev/rte_crypto.h
> index 0908368..9f10818 100644
> --- a/lib/librte_cryptodev/rte_crypto.h
> +++ b/lib/librte_cryptodev/rte_crypto.h
> @@ -266,8 +266,8 @@ rte_crypto_op_alloc(struct rte_mempool *mempool, enum
> rte_crypto_op_type type)
> * @paramnb_ops Number of crypto operations to allocate
> *
> * @returns
> - * - On success returns a valid rte_crypto_op structure
> - * - On failure returns NULL
> + * - 0 if no operations could be allocated
> + * - nb_ops if the number of operations requested were allocated
> */
>
My first thought was what's returned if some ops could be allocated, but not
the requested number?
Maybe instead:
- nb_ops if the number of operations requested were allocated.
- 0 if the requested number of ops are not available. None are allocated in
this case.
> static inline unsigned
> --
> 2.9.4
[dpdk-dev] [PATCH] doc: fix missing section underline
Fixes: b59502a5e3d0 ("cryptodev: add AEAD parameters in crypto operation")
Signed-off-by: Pablo de Lara
---
doc/guides/prog_guide/cryptodev_lib.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
b/doc/guides/prog_guide/cryptodev_lib.rst
index 568b539..81a6b1f 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -424,6 +424,7 @@ operations, as well as also supporting AEAD operations.
Session and Session Management
+~~
Sessions are used in symmetric cryptographic processing to store the immutable
data defined in a cryptographic transform which is used in the operation
--
2.9.4
Re: [dpdk-dev] [PATCH] crypto/qat: fix SHA384-HMAC block size
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, July 25, 2017 7:34 AM
> To: Trahe, Fiona ; Jain, Deepak K
> ; Griffin, John
>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo ;
> sta...@dpdk.org
> Subject: [PATCH] crypto/qat: fix SHA384-HMAC block size
>
> Block size of SHA384-HMAC algorithm is 128 bytes,
> and not 64 bytes.
>
> Fixes: d905ee32d0dc ("crypto/qat: add aes-sha384-hmac capability")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Pablo de Lara
Acked-by: Fiona Trahe
Re: [dpdk-dev] [PATCH 3/3] crypto/qat: fix HMAC supported key sizes
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, July 25, 2017 6:25 AM
> To: zbigniew.bo...@caviumnetworks.com; jerin.ja...@caviumnetworks.com;
> akhil.go...@nxp.com;
> hemant.agra...@nxp.com; Trahe, Fiona ; Jain, Deepak K
> ; Griffin, John ; Doherty,
> Declan
>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo ;
> sta...@dpdk.org
> Subject: [PATCH 3/3] crypto/qat: fix HMAC supported key sizes
>
> For HMAC algorithms (MD5-HMAC, SHAx-HMAC), the supported
> key sizes are not a fixed value, but a range between
> 1 and the block size.
>
> Fixes: 26c2e4ad5ad4 ("cryptodev: add capabilities discovery")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Pablo de Lara
Acked-by: Fiona Trahe
Re: [dpdk-dev] [PATCH v2] cryptodev: fix session init return value
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, July 25, 2017 7:17 AM
> To: zbigniew.bo...@caviumnetworks.com; jerin.ja...@caviumnetworks.com;
> akhil.go...@nxp.com;
> hemant.agra...@nxp.com; Trahe, Fiona ; Jain, Deepak K
> ; Griffin, John ; Doherty,
> Declan
>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo
> Subject: [PATCH v2] cryptodev: fix session init return value
>
> When calling rte_cryptodev_sym_session_init(),
> if there was an error, it returned -1, instead
> of returning the specific error code, which can
> be valuable for the application for error handling.
>
> Fixes: b3bbd9e5f265 ("cryptodev: support device independent sessions")
>
> Signed-off-by: Pablo de Lara
> Acked-by: Akhil Goyal
Acked-by: Fiona Trahe
Re: [dpdk-dev] [dpdk-users] SR-IOV problem with dpdk drivers
+dev-dpdk can help here.. I have removed SR-IOV and made those interfaces as PIC-passthrough and that is working without any issues. So, Yes! this could be problem with virtual function driver(i40evf). Thanks On Thu, Jul 27, 2017 at 8:30 AM, Raju-dev grishma wrote: > Linux driver works, DPDK older version works but not dpdk 17.05. > Then it seems the dpdk driver of 17.05 has some issues to work with vmware > hypervisors. > > > > On Wed, Jul 26, 2017 at 6:38 PM, SAKTHIVEL ANAND S > wrote: > >> Thanks Raju.. >> >> These SR-IOV interfaces are reachable with linux drivers and also i have >> verified with dpdk 2.2.0, which is running without any issues. >> But when i bring in dpdk17.05, it failed to come up with above mentioned >> error messages. >> >> please help me if, is it known issue with new SR-IOV drivers? or did i >> miss something? >> >> -Sakthivel S >> >> On Wed, Jul 26, 2017 at 6:02 PM, Raju-dev grishma >> wrote: >> >>> hello Sakthivel, >>> Can you try if on this VM, the kernel can see the interfaces and ping >>> works with those interfaces? >>> Secondly did you try with older version of DPDK ? >>> >>> Tx >>> >>> >>> On Wed, Jul 26, 2017 at 5:05 PM, SAKTHIVEL ANAND S >> > wrote: >>> i just upgraded the Intel NIC firmware and still there is no improvement for this.. It is falling under same issue. Following are NIC firmware details. ethtool -i vmnic4 driver: i40e version: 1.3.45 firmware-version: 5.60 0x80002dab 1.1618.0 bus-info: :05:00.0 Can someone pls help me to fix this. is this known issue, or did i missed something? Thanks in Advance Sakthivel S OM On Thu, Jul 20, 2017 at 7:06 PM, Kyle Larose wrote: > I’m not an expert, but my guess is that your PF is running a very > different version of the i40e driver, and because of this the two cannot > communicate. I personally have never seen this before. Perhaps google has? > > > > *From:* SAKTHIVEL ANAND S [mailto:anand.s...@gmail.com] > *Sent:* Thursday, July 20, 2017 6:57 PM > *To:* Kyle Larose > *Cc:* us...@dpdk.org > *Subject:* Re: [dpdk-users] SR-IOV problem with dpdk drivers > > > > Thanks Kyle , yes i loaded the .ko files and i am able to bind to DPDK > driver now. But when i am running testpmd, it shows the below error message. > > root@ubuntu:~/dpdk-stable-17.05.1/bin# ./testpmd -c7 -n1 -- -i > --nb-cores=2 --nb-ports=2 --total-num-mbufs=1024 > EAL: Detected 8 lcore(s) > EAL: No free hugepages reported in hugepages-1048576kB > EAL: Probing VFIO support... > > > > *EAL: PCI device :03:00.0 on NUMA socket -1 EAL: probe driver: > 8086:154c net_i40e_vf i40evf_init_vf(): init_adminq failed > i40evf_dev_init(): Init vf failed* > EAL: Requested device :03:00.0 cannot be used > EAL: PCI device :04:00.0 on NUMA socket -1 > EAL: probe driver: 15ad:7b0 net_vmxnet3 > > > > > *EAL: PCI device :0b:00.0 on NUMA socket -1 EAL: probe driver: > 8086:154c net_i40e_vf i40evf_check_api_version(): PF/VF API version > mismatch:(0.0)-(1.1) i40evf_init_vf(): check_api version failed > i40evf_dev_init(): Init vf failed* > EAL: Requested device :0b:00.0 cannot be used > EAL: PCI device :13:00.0 on NUMA socket -1 > EAL: probe driver: 15ad:7b0 net_vmxnet3 > EAL: PCI device :1b:00.0 on NUMA socket -1 > EAL: probe driver: 15ad:7b0 net_vmxnet3 > EAL: No probed ethernet devices > Interactive-mode selected > EAL: Error - exiting with code: 1 > Cause: Invalid port 2 > > pls help me ti resolve this. > > Thanks > > Sakthivel S OM > > > > On Thu, Jul 20, 2017 at 4:01 PM, Kyle Larose wrote: > > Hi > > > -Original Message- > > From: users [mailto:users-boun...@dpdk.org] On Behalf Of SAKTHIVEL > > ANAND S > > Sent: Thursday, July 20, 2017 3:05 PM > > To: us...@dpdk.org > > Subject: [dpdk-users] SR-IOV problem with dpdk drivers > > > > Hi > > > > I am facing problem when i tried to bring up my SR-IOV interfaces in to > dpdk > > compatible driver.. > > could someone pls help where i have missed? > > > > ERROR: > > > > root@ubuntu:~# ./dpdk-devbind.py -b igb_uio 0b:00.0 > > Error: bind failed for :0b:00.0 - Cannot open > > /sys/bus/pci/drivers/igb_uio/bind > > > > > Is the igb_uio kernel module loaded? lsmod should say. If not, run > 'modprobe igb_uio', then try again. > > > > DPDK: 17.05.1 > > ubuntu:16.04.2 > > Nic: Intel XL710/X710 > > -- > > Thanks > > Sakthivel S OM > > > > > --
Re: [dpdk-dev] [PATCH 2/3] crypto/openssl: fix HMAC supported key sizes
On 25/07/2017 6:24 AM, Pablo de Lara wrote:
For HMAC algorithms (MD5-HMAC, SHAx-HMAC), the supported
key sizes are not a fixed value, but a range between
1 and the block size.
Fixes: d61f70b4c918 ("crypto/libcrypto: add driver for OpenSSL library")
Cc: sta...@dpdk.org
Signed-off-by: Pablo de Lara
---
...
Acked-by: Declan Doherty
Re: [dpdk-dev] [PATCH 1/3] crypto/aesni_mb: fix HMAC supported key sizes
On 25/07/2017 6:24 AM, Pablo de Lara wrote:
For HMAC algorithms (MD5-HMAC, SHAx-HMAC), the supported
key sizes are not a fixed value, but a range between
1 and the block size.
Fixes: 26c2e4ad5ad4 ("cryptodev: add capabilities discovery")
Cc: sta...@dpdk.org
Signed-off-by: Pablo de Lara
---
...
Acked-by: Declan Doherty
Re: [dpdk-dev] [PATCH] cryptodev: deprecate rte_cryptodev_create_vdev()
On 12/07/2017 9:15 PM, Jan Blunck wrote: This function is an alias for rte_vdev_init() which is scheduled to move out of the rte_eal library. Lets deprecate this function to be able to remove it from the cryptodev library in 17.11. Signed-off-by: Jan Blunck --- ... Acked-by: Declan Doherty
[dpdk-dev] [PATCH v2] net/mlx4: fix flow creation before start
The corrupted code causes segmentation fault when user creates
flow with drop action before device starting.
For example, failsafe PMD recreates all the flows before calling
dev_start in plug-in sequence and mlx4 allocated its flow drop
queue in dev_start.
Hence, when failsafe created flow with drop action after plug-in
event, mlx4 tried to dereference flow drop queue which was uninitialized.
The fix added check to the drop qp accesibale and conditioned the
ibv_create_flow calling on device starting.
Fixes: 642fe56a1ba5 ("net/mlx4: use a single drop queue for all drop flows")
Fixes: 46d5736a7049 ("net/mlx4: support basic flow items and actions")
Cc: sta...@dpdk.org
Signed-off-by: Matan Azrad
Acked-by: Adrien Mazarguil
---
drivers/net/mlx4/mlx4_flow.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
v2 to fix the qp accesible by other way and fix the ibv_create_flow calling
before dev_start.
diff --git a/drivers/net/mlx4/mlx4_flow.c b/drivers/net/mlx4/mlx4_flow.c
index 8ade106..925c89c 100644
--- a/drivers/net/mlx4/mlx4_flow.c
+++ b/drivers/net/mlx4/mlx4_flow.c
@@ -977,7 +977,7 @@ struct rte_flow_drop {
return NULL;
}
if (action->drop) {
- qp = priv->flow_drop_queue->qp;
+ qp = priv->flow_drop_queue ? priv->flow_drop_queue->qp : NULL;
} else {
int ret;
unsigned int i;
@@ -1015,6 +1015,8 @@ struct rte_flow_drop {
rte_flow->qp = qp;
}
rte_flow->ibv_attr = ibv_attr;
+ if (!priv->started)
+ return rte_flow;
rte_flow->ibv_flow = ibv_create_flow(qp, rte_flow->ibv_attr);
if (!rte_flow->ibv_flow) {
rte_flow_error_set(error, ENOMEM, RTE_FLOW_ERROR_TYPE_HANDLE,
--
1.8.3.1
Re: [dpdk-dev] Question on mlx5 PMD txq memory registration
Well, this is a fair argument, but without a *complete* solution for all of dpdk peripherals, it has very little merit (if at all). A badly written code can just as easily crash a server by passing a mbuf to a crypto device or another network device that co-exists with mlx5. So, while I understand the argument, I think its value is not worth the hassle that mlx5_pmd needs to take to achieve it. Did this come from a real requirement (from a real implementation)? Would using VFIO (and the IOMMU) not allow us to provide an equivalent level of security to what is provided by the current scheme? mlx5 does not take over the device with vfio, it simply asks the kernel to setup resources for it and sets a mac steering rule to direct traffic to its own rings. Also, I'm not aware of any way to enforce iommu is enabled. From what I see on-list there are a few folks already looking into that area, and taking advantage of the IOMMU should improve security of all devices in DPDK. I agree that this can be improved in dpdk, I was simply arguing that mlx5 guarantees alone are not very valuable, especially considering the work-arounds taken in mlx5 to achieve it. mlx5 can be converted to take over the device with vfio and simply not deal with memory registration aspects, but that is really up to mlx5 maintainers.
Re: [dpdk-dev] [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
Hi Jerin and all,
There are a few inconsistencies/complexities that I ran into with the
implementation of the SW Rx event adapter, I have first summarized this
email thread bringing together details scattered across various
exchanges then I want to check if there are changes possible that would
simplify the implementation of the SW Rx event adapter.
The Rx event adapter needs to support the following scenarios:
1) Ethdev HW is not capable of injecting the packets and SW eventdev
driver(All existing ethdev PMD + drivers/event/sw PMD combination)
2) Ethdev HW is not capable of injecting the packets and not compatible
HW eventdev driver(All existing ethdev PMD + driver/event/octeontx PMD
combination)
3) Ethdev HW is capable of injecting the packet to compatible
HW eventdev driver.
cases 1) and 2) above are not different. In both cases we need a SW
thread that will inject packets from the ethdev PMD to an event dev PMD.
The APIs proposed are:
int rte_event_eth_rx_adapter_create(uint8_t dev_id,
uint8_t eth_port_id, uint8_t id /* adapter ID */);
An adapter created above has an ops struct, where the ops
struct provides implementations for the functions below.
The ops struct chosen for the adapter depends on the eth_port_id> combination.
struct rte_event_eth_rx_adap_info {
uint32_t cap;
/* adapter has inbuilt port, no need to create producer port */
#define RTE_EVENT_ETHDEV_CAP_INBUILT_PORT (1ULL << 0)
/* adapter does not need service function */
#define RTE_EVENT_ETHDEV_CAP_NO_SERVICE_FUNC (1ULL << 1)
}
int rte_event_eth_rx_adapter_get_info(uint8_t dev_id, uint8_t id,
struct rte_event_eth_rx_adap_info *info);
struct rte_event_eth_rx_adapter_conf {
/* Application specified service function name */
char service_name[];
uint8_t rx_event_port_id;
/**< Event port identifier, the adapter enqueues mbuf
* events to this
* port, Ignored when RTE_EVENT_ETHDEV_CAP_INBUILT_PORT
*/
}
int rte_event_eth_rx_adapter_configure(uint8_t dev_id, uint8_t id
struct rte_event_eth_rx_adapter_conf *cfg);
struct rte_event_eth_rx_adapter_queue_conf {
... event info ...
uint16_t servicing_weight;
/**< Relative polling frequency of ethernet receive queue, if this
* is set to zero, the Rx queue is interrupt driven (unless rx queue
* interrupts are not enabled for the ethernet device)
*/
...
}
int rte_event_eth_rx_adapter_queue_add(uint8_t dev_id,
uint8_t id, int32_t rx_queue_id,
const struct rte_eth_rx_event_adapter_queue_conf *config);
int rte_event_eth_rx_adapter_queue_del(uint8_t dev_id,
uint8_t id, int32_t rx_queue_id)
In the case of a SW thread we would like to use the servicing weight
specified in the queue to do WRR across , in keeping
with the adaper per model, one way to do this is to
use the same cfg.service_name in the
rte_event_eth_rx_adapter_configure() call.
However this creates a few difficulties/inconsistencies:
1)Service has the notion of a socket id. Multiple event dev IDs can be
included in the same service, each event dev has a socket ID -> this
seems to be an inconsistency that shouldn’t be allowed by design.
2)Say, the Rx event adapter doesn’t drop packets (could be
configurable), i.e, if events cannot be enqueued into the event device,
these remain in a buffer, when the buffer fills up packets aren’t
dequeued from the eth device.
In the simplest case the Rx event adapter service has a single device, event port> across multiple eth ports, it dequeues from the
wrr[] and buffers events, bulk enqueues BATCH_SIZE events into the
.
With adapters having different code can be
optimized so that adapters that have a common
can be made to refer to a common enqueue buffer { event dev, event port,
buffer } structure but this adds more book keeping in the code.
3)Every adapter can be configured with max_nb_rx ( a max nb of packets
that it can process in any invocation) – but the max_nb_rx seems like a
service level parameter instead of it being a summation across adapters.
1 & 3 could be solved by restricting the adapters to the same (as in the
first rte_event_eth_rx_adapter_configure() call) socket ID, and perhaps
using the max value of max_nb_rx or using the same value of max_nb_rx
across adapters. #2 is doable but has a bit of code complexity to handle
the generic case.
Before we go there, I wanted to check if there is an alternative
possible that would remove the difficulties above. Essentially allow
multiple ports within an adapter but avoid the problem of the
inconsistent combinations when using multiple ports
with a single eventdev.
Instead of
==
rte_event_eth_rx_adapter_create()
rte_event_eth_rx_adapter_get_info();
rte_event_eth_rx_adapter_configure();
rte_event_eth_rx_adapter_queue_add();
==
How about ?
==
rte_event_eth_rx_adapter_get_info(uint8_t dev_id, uint8_t eth_port_id,
s
Re: [dpdk-dev] [PATCH] net/mlx5: poll completion queue once per a call
Yes I realize that, but can't the device still complete in a burst (of unsuppressed completions)? I mean its not guaranteed that for every txq_complete a signaled completion is pending right? What happens if the device has inconsistent completion pacing? Can't the sw grow a batch of completions if txq_complete will process a single completion unconditionally? Speculation. First of all, device doesn't delay completion notifications for no reason. ASIC is not a SW running on top of a OS. I'm sorry but this statement is not correct. It might be correct in a lab environment, but in practice, there are lots of things that can affect the device timing. If a completion comes up late, this means device really can't keep up the rate of posting descriptors. If so, tx_burst() should generate back-pressure by returning partial Tx, then app can make a decision between drop or retry. Retry on Tx means back-pressuring Rx side if app is forwarding packets. Not arguing on that, I was simply suggesting that better heuristics could be applied than "process one completion unconditionally". More serious problem I expected was a case that the THRESH is smaller than burst size. In that case, txq->elts[] will be short of slots all the time. But fortunately, in MLX PMD, we request one completion per a burst at most, not every THRESH of packets. If there's some SW jitter on Tx processiong, the Tx CQ can grow for sure. Question to myself was "when does it shrink?". It shrinks when Tx burst is light (burst size is smaller than THRESH) because mlx5_tx_complete() is always called every time tx_burst() is called. What if it keeps growing? Then, drop is necessary and natural like I mentioned above. It doesn't make sense for SW to absorb any possible SW jitters. Cost is high. It is usually done by increasing queue depth. Keeping steady state is more important. Again, I agree jitters are bad, but with proper heuristics in place mlx5 can still keep a low jitter _and_ consume completions faster than consecutive tx_burst invocations. Rather, this patch is helpful for reducing jitters. When I run a profiler, the most cycle-consuming part on Tx is still freeing buffers. If we allow loops on checking valid CQE, many buffers could be freed in a single call of mlx5_tx_complete() at some moment, then it would cause a long delay. This would aggravate jitter. I didn't argue the fact that this patch addresses an issue, but mlx5 is a driver that is designed to run applications that can act differently than your test case. Of course. I appreciate your time for the review. And keep in mind that nothing is impossible in an open source community. I always like to discuss about ideas with anyone. But I was just asking to hear more details about your suggestion if you wanted me to implement it, rather than giving me one-sentence question :-) Good to know. Does "budget" mean the threshold? If so, calculation of stats for adaptive threshold can impact single core performance. With multiple cores, adjusting threshold doesn't affect much. If you look at mlx5e driver in the kernel, it maintains online stats on its RX and TX queues. It maintain these stats mostly for adaptive interrupt moderation control (but not only). I was suggesting maintaining per TX queue stats on average completions consumed for each TX burst call, and adjust the stopping condition according to a calculated stat. In case of interrupt mitigation, it could be beneficial because interrupt handling cost is too costly. But, the beauty of DPDK is polling, isn't it? If you read again my comment, I didn't suggest to apply stats for interrupt moderation, I just gave an example of a use-case. I was suggesting to maintain the online stats for adjusting a threshold of how much completions to process in a tx burst call (instead of processing one unconditionally). And please remember to ack at the end of this discussion if you are okay so that this patch can gets merged. One data point is, single core performance (fwd) of vectorized PMD gets improved by more than 6% with this patch. 6% is never small. Yea, I don't mind merging it in given that I don't have time to come up with anything better (or worse :)) Reviewed-by: Sagi Grimberg
Re: [dpdk-dev] [PATCH] crypto/dpaa2_sec: add check for gcc toolchain
On 7/27/2017 2:22 PM, De Lara Guarch, Pablo wrote:
HI Akhil,
-Original Message-
From: Akhil Goyal [mailto:akhil.go...@nxp.com]
Sent: Wednesday, July 26, 2017 12:28 PM
To: dev@dpdk.org
Cc: De Lara Guarch, Pablo ;
hemant.agra...@nxp.com; Akhil Goyal
Subject: [PATCH] crypto/dpaa2_sec: add check for gcc toolchain
Signed-off-by: Akhil Goyal
I think you need to include a fixes line here, and CC stable, as this is a fix.
This is not valid for 17.05 stable release. This is recently added in
below commit. Should I resend this patch with commit message updated?
ed5ed6b344f2 ("crypto/dpaa2_sec: remove GCC 7.1 compilation error")
Thanks,
Akhil
[dpdk-dev] [PATCH] crypto/dpaa2_sec: fix HMAC supported key sizes
For HMAC algorithms (MD5-HMAC, SHAx-HMAC), the supported
key sizes are not a fixed value, but a range between
1 and the block size.
Fixes: 623326dded3a ("crypto/dpaa2_sec: introduce poll mode driver")
Cc: sta...@dpdk.org
Signed-off-by: Akhil Goyal
---
drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
b/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
index e104f71..3849a05 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
@@ -200,9 +200,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_MD5_HMAC,
.block_size = 64,
.key_size = {
- .min = 64,
+ .min = 1,
.max = 64,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 16,
@@ -221,9 +221,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
.block_size = 64,
.key_size = {
- .min = 64,
+ .min = 1,
.max = 64,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 20,
@@ -242,9 +242,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_SHA224_HMAC,
.block_size = 64,
.key_size = {
- .min = 64,
+ .min = 1,
.max = 64,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 28,
@@ -263,9 +263,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_SHA256_HMAC,
.block_size = 64,
.key_size = {
- .min = 64,
+ .min = 1,
.max = 64,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 32,
@@ -284,9 +284,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_SHA384_HMAC,
.block_size = 128,
.key_size = {
- .min = 128,
+ .min = 1,
.max = 128,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 48,
@@ -305,9 +305,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_SHA512_HMAC,
.block_size = 128,
.key_size = {
- .min = 128,
+ .min = 1,
.max = 128,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 64,
--
2.9.3
[dpdk-dev] [PATCH] bonding: fix wrong slaves capacity check
For fortville NIC bond_ethdev_8023ad_flow_verify fails when action queue
index indicates unavailable queue before slaves configuration.
This fix verifies flow settings for queue 0, which is always available,
and checks if slaves max queue number capacity meets requirements.
Fixes: 112891cd27e5 ("net/bonding: add dedicated HW queues for LACP control")
Signed-off-by: Tomasz Kulasek
---
drivers/net/bonding/rte_eth_bond_pmd.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 8f9a860..ab5ebe0 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -175,12 +175,13 @@ const struct rte_flow_attr flow_attr_8023ad = {
int
bond_ethdev_8023ad_flow_verify(struct rte_eth_dev *bond_dev,
uint8_t slave_port) {
+ struct rte_eth_dev_info slave_info;
struct rte_flow_error error;
struct bond_dev_private *internals = (struct bond_dev_private *)
(bond_dev->data->dev_private);
- struct rte_flow_action_queue lacp_queue_conf = {
- .index = internals->mode4.dedicated_queues.rx_qid,
+ const struct rte_flow_action_queue lacp_queue_conf = {
+ .index = 0,
};
const struct rte_flow_action actions[] = {
@@ -195,8 +196,22 @@ bond_ethdev_8023ad_flow_verify(struct rte_eth_dev
*bond_dev,
int ret = rte_flow_validate(slave_port, &flow_attr_8023ad,
flow_item_8023ad, actions, &error);
- if (ret < 0)
+ if (ret < 0) {
+ RTE_BOND_LOG(ERR, "bond_ethdev_8023ad_flow_verify: %s "
+ "(slave_port=%d queue_id=%d)",
+ error.message, slave_port,
+ internals->mode4.dedicated_queues.rx_qid);
+ return -1;
+ }
+
+ rte_eth_dev_info_get(slave_port, &slave_info);
+ if ((slave_info.max_rx_queues < bond_dev->data->nb_rx_queues) ||
+ (slave_info.max_tx_queues <
bond_dev->data->nb_tx_queues)) {
+ RTE_BOND_LOG(ERR, "bond_ethdev_8023ad_flow_verify: Slave %d"
+ " capabilities doesn't allow to allocate "
+ "additional queues", slave_port);
return -1;
+ }
return 0;
}
@@ -206,7 +221,7 @@ bond_8023ad_slow_pkt_hw_filter_supported(uint8_t port_id) {
struct rte_eth_dev *bond_dev = &rte_eth_devices[port_id];
struct bond_dev_private *internals = (struct bond_dev_private *)
(bond_dev->data->dev_private);
- struct rte_eth_dev_info bond_info, slave_info;
+ struct rte_eth_dev_info bond_info;
uint8_t idx;
/* Verify if all slaves in bonding supports flow director and */
@@ -217,9 +232,6 @@ bond_8023ad_slow_pkt_hw_filter_supported(uint8_t port_id) {
internals->mode4.dedicated_queues.tx_qid =
bond_info.nb_tx_queues;
for (idx = 0; idx < internals->slave_count; idx++) {
- rte_eth_dev_info_get(internals->slaves[idx].port_id,
- &slave_info);
-
if (bond_ethdev_8023ad_flow_verify(bond_dev,
internals->slaves[idx].port_id) != 0)
return -1;
--
2.7.4
Re: [dpdk-dev] [PATCH] crypto/dpaa2_sec: add check for gcc toolchain
Hi,
> -Original Message-
> From: Akhil Goyal [mailto:akhil.go...@nxp.com]
> Sent: Thursday, July 27, 2017 12:43 PM
> To: De Lara Guarch, Pablo ;
> dev@dpdk.org
> Cc: hemant.agra...@nxp.com
> Subject: Re: [PATCH] crypto/dpaa2_sec: add check for gcc toolchain
>
> On 7/27/2017 2:22 PM, De Lara Guarch, Pablo wrote:
> > HI Akhil,
> >
> >> -Original Message-
> >> From: Akhil Goyal [mailto:akhil.go...@nxp.com]
> >> Sent: Wednesday, July 26, 2017 12:28 PM
> >> To: dev@dpdk.org
> >> Cc: De Lara Guarch, Pablo ;
> >> hemant.agra...@nxp.com; Akhil Goyal
> >> Subject: [PATCH] crypto/dpaa2_sec: add check for gcc toolchain
> >>
> >> Signed-off-by: Akhil Goyal
> >
> > I think you need to include a fixes line here, and CC stable, as this is a
> > fix.
> >
>
> This is not valid for 17.05 stable release. This is recently added in below
> commit. Should I resend this patch with commit message updated?
>
> ed5ed6b344f2 ("crypto/dpaa2_sec: remove GCC 7.1 compilation error")
Oh, you are right. Well, I can add the line for you.
Thanks,
Pablo
>
> Thanks,
> Akhil
Re: [dpdk-dev] [PATCH] crypto/dpaa2_sec: fix HMAC supported key sizes
On 7/27/2017 5:24 PM, Akhil Goyal wrote:
For HMAC algorithms (MD5-HMAC, SHAx-HMAC), the supported
key sizes are not a fixed value, but a range between
1 and the block size.
Fixes: 623326dded3a ("crypto/dpaa2_sec: introduce poll mode driver")
Cc: sta...@dpdk.org
Signed-off-by: Akhil Goyal
---
drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
b/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
index e104f71..3849a05 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
@@ -200,9 +200,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_MD5_HMAC,
.block_size = 64,
.key_size = {
- .min = 64,
+ .min = 1,
.max = 64,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 16,
@@ -221,9 +221,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
.block_size = 64,
.key_size = {
- .min = 64,
+ .min = 1,
.max = 64,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 20,
@@ -242,9 +242,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_SHA224_HMAC,
.block_size = 64,
.key_size = {
- .min = 64,
+ .min = 1,
.max = 64,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 28,
@@ -263,9 +263,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_SHA256_HMAC,
.block_size = 64,
.key_size = {
- .min = 64,
+ .min = 1,
.max = 64,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 32,
@@ -284,9 +284,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_SHA384_HMAC,
.block_size = 128,
.key_size = {
- .min = 128,
+ .min = 1,
.max = 128,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 48,
@@ -305,9 +305,9 @@ static const struct rte_cryptodev_capabilities
dpaa2_sec_capabilities[] = {
.algo = RTE_CRYPTO_AUTH_SHA512_HMAC,
.block_size = 128,
.key_size = {
- .min = 128,
+ .min = 1,
.max = 128,
- .increment = 0
+ .increment = 1
},
.digest_size = {
.min = 64,
Acked-by: Hemant Agrawal
Re: [dpdk-dev] [PATCH] crypto/dpaa2_sec: fix HMAC supported key sizes
> -Original Message-
> From: Hemant Agrawal [mailto:hemant.agra...@nxp.com]
> Sent: Thursday, July 27, 2017 2:58 PM
> To: Akhil Goyal ; dev@dpdk.org
> Cc: De Lara Guarch, Pablo ;
> sta...@dpdk.org
> Subject: Re: [PATCH] crypto/dpaa2_sec: fix HMAC supported key sizes
>
> On 7/27/2017 5:24 PM, Akhil Goyal wrote:
> > For HMAC algorithms (MD5-HMAC, SHAx-HMAC), the supported key sizes
> are
> > not a fixed value, but a range between
> > 1 and the block size.
> >
> > Fixes: 623326dded3a ("crypto/dpaa2_sec: introduce poll mode driver")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Akhil Goyal
...
> >
> Acked-by: Hemant Agrawal
Applied to dpdk-next-crypto.
Thanks,
Pablo
Re: [dpdk-dev] [PATCH] crypto/dpaa2_sec: add check for gcc toolchain
> -Original Message-
> From: Akhil Goyal [mailto:akhil.go...@nxp.com]
> Sent: Thursday, July 27, 2017 12:43 PM
> To: De Lara Guarch, Pablo ;
> dev@dpdk.org
> Cc: hemant.agra...@nxp.com
> Subject: Re: [PATCH] crypto/dpaa2_sec: add check for gcc toolchain
>
> On 7/27/2017 2:22 PM, De Lara Guarch, Pablo wrote:
> > HI Akhil,
> >
> >> -Original Message-
> >> From: Akhil Goyal [mailto:akhil.go...@nxp.com]
> >> Sent: Wednesday, July 26, 2017 12:28 PM
> >> To: dev@dpdk.org
> >> Cc: De Lara Guarch, Pablo ;
> >> hemant.agra...@nxp.com; Akhil Goyal
> >> Subject: [PATCH] crypto/dpaa2_sec: add check for gcc toolchain
> >>
> >> Signed-off-by: Akhil Goyal
> >
> > I think you need to include a fixes line here, and CC stable, as this is a
> > fix.
> >
>
> This is not valid for 17.05 stable release. This is recently added in below
> commit. Should I resend this patch with commit message updated?
>
> ed5ed6b344f2 ("crypto/dpaa2_sec: remove GCC 7.1 compilation error")
>
> Thanks,
> Akhil
Added fixes line [Fixes: 6a95466d78de ("crypto/dpaa2_sec: fix build with gcc
7.1")].
Remember to use the commit ID of the patch that was actually merged.
Applied to dpdk-next-crypto.
Thanks,
Pablo
Re: [dpdk-dev] [PATCH 0/3] HMAC supported key size fixes
> -Original Message- > From: De Lara Guarch, Pablo > Sent: Tuesday, July 25, 2017 6:25 AM > To: zbigniew.bo...@caviumnetworks.com; > jerin.ja...@caviumnetworks.com; akhil.go...@nxp.com; > hemant.agra...@nxp.com; Trahe, Fiona ; Jain, > Deepak K ; Griffin, John > ; Doherty, Declan > Cc: dev@dpdk.org; De Lara Guarch, Pablo > > Subject: [PATCH 0/3] HMAC supported key size fixes > > For HMAC algorithms (SHAx/MD5), the capabilities were not correct, as > they were just a fixed value (block size). > Instead, the authentication key size for these algorithms can go between 1 > and the block size. > > Note that these patches are fixing AESNI-MB, OpenSSL and QAT PMDs, but > DPAA2 and ARMv8 crypto PMDs might need these fixes too. > > Pablo de Lara (3): > crypto/aesni_mb: fix HMAC supported key sizes > crypto/openssl: fix HMAC supported key sizes > crypto/qat: fix HMAC supported key sizes > > drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 24 -- > -- > drivers/crypto/openssl/rte_openssl_pmd_ops.c | 24 --- > - > drivers/crypto/qat/qat_crypto_capabilities.h | 24 --- > - > 3 files changed, 36 insertions(+), 36 deletions(-) > > -- > 2.9.4 Applied to dpdk-next-crypto. Pablo
Re: [dpdk-dev] [PATCH] crypto/qat: fix SHA384-HMAC block size
> -Original Message-
> From: Trahe, Fiona
> Sent: Thursday, July 27, 2017 10:42 AM
> To: De Lara Guarch, Pablo ; Jain, Deepak K
> ; Griffin, John
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH] crypto/qat: fix SHA384-HMAC block size
>
>
>
> > -Original Message-
> > From: De Lara Guarch, Pablo
> > Sent: Tuesday, July 25, 2017 7:34 AM
> > To: Trahe, Fiona ; Jain, Deepak K
> > ; Griffin, John
> > Cc: dev@dpdk.org; De Lara Guarch, Pablo
> > ; sta...@dpdk.org
> > Subject: [PATCH] crypto/qat: fix SHA384-HMAC block size
> >
> > Block size of SHA384-HMAC algorithm is 128 bytes, and not 64 bytes.
> >
> > Fixes: d905ee32d0dc ("crypto/qat: add aes-sha384-hmac capability")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Pablo de Lara
> Acked-by: Fiona Trahe
Applied to dpdk-next-crypto.
Pablo
Re: [dpdk-dev] [PATCH v2] cryptodev: fix session init return value
> -Original Message-
> From: Trahe, Fiona
> Sent: Thursday, July 27, 2017 11:12 AM
> To: De Lara Guarch, Pablo ;
> zbigniew.bo...@caviumnetworks.com; jerin.ja...@caviumnetworks.com;
> akhil.go...@nxp.com; hemant.agra...@nxp.com; Jain, Deepak K
> ; Griffin, John ; Doherty,
> Declan
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v2] cryptodev: fix session init return value
>
>
>
> > -Original Message-
> > From: De Lara Guarch, Pablo
> > Sent: Tuesday, July 25, 2017 7:17 AM
> > To: zbigniew.bo...@caviumnetworks.com;
> jerin.ja...@caviumnetworks.com;
> > akhil.go...@nxp.com; hemant.agra...@nxp.com; Trahe, Fiona
> > ; Jain, Deepak K ;
> > Griffin, John ; Doherty, Declan
> >
> > Cc: dev@dpdk.org; De Lara Guarch, Pablo
> >
> > Subject: [PATCH v2] cryptodev: fix session init return value
> >
> > When calling rte_cryptodev_sym_session_init(), if there was an error,
> > it returned -1, instead of returning the specific error code, which
> > can be valuable for the application for error handling.
> >
> > Fixes: b3bbd9e5f265 ("cryptodev: support device independent sessions")
> >
> > Signed-off-by: Pablo de Lara
> > Acked-by: Akhil Goyal
> Acked-by: Fiona Trahe
Applied to dpdk-next-crypto.
Pablo
Re: [dpdk-dev] [PATCH] doc: fix missing section underline
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Thursday, July 27, 2017 2:25 AM
> To: Mcnamara, John
> Cc: dev@dpdk.org; De Lara Guarch, Pablo
>
> Subject: [PATCH] doc: fix missing section underline
>
> Fixes: b59502a5e3d0 ("cryptodev: add AEAD parameters in crypto
> operation")
>
> Signed-off-by: Pablo de Lara
Applied to dpdk-next-crypto.
Pablo
Re: [dpdk-dev] [PATCH] doc: fix l2fwd-crypto sample code
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Wednesday, July 26, 2017 12:33 AM
> To: Mcnamara, John ; Doherty, Declan
>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo
>
> Subject: [PATCH] doc: fix l2fwd-crypto sample code
>
> L2fwd-crypto app was modified with various changes in its code. The
> application user guide contains some code snippets that needed to be
> updated.
>
> Fixes: 2661f4fbe93d ("examples/l2fwd-crypto: add AEAD parameters")
>
> Signed-off-by: Pablo de Lara
Applied to dpdk-next-crypto.
Pablo
Re: [dpdk-dev] [PATCH] cryptodev: fix crypto op bulk alloc Doxygen
> -Original Message-
> From: Trahe, Fiona
> Sent: Thursday, July 27, 2017 10:03 AM
> To: De Lara Guarch, Pablo ; Doherty,
> Declan
> Cc: dev@dpdk.org; De Lara Guarch, Pablo
> ; sta...@dpdk.org; Trahe, Fiona
>
> Subject: RE: [dpdk-dev] [PATCH] cryptodev: fix crypto op bulk alloc Doxygen
>
> Hi Pablo,
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pablo de Lara
> > Sent: Wednesday, July 26, 2017 5:27 AM
> > To: Doherty, Declan
> > Cc: dev@dpdk.org; De Lara Guarch, Pablo
> > ; sta...@dpdk.org
> > Subject: [dpdk-dev] [PATCH] cryptodev: fix crypto op bulk alloc
> > Doxygen
> >
> > When calling rte_crypto_op_bulk_alloc, the function may return either
> > a 0, if not enough objects are available in the mempool or the number
> > of operations requested, it there are enough available. However, the
> > Doxygen comments were not matching these two cases.
> >
> > Fixes: c0f87eb5252b ("cryptodev: change burst API to be crypto op
> > oriented")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Pablo de Lara
> > ---
> > lib/librte_cryptodev/rte_crypto.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/librte_cryptodev/rte_crypto.h
> > b/lib/librte_cryptodev/rte_crypto.h
> > index 0908368..9f10818 100644
> > --- a/lib/librte_cryptodev/rte_crypto.h
> > +++ b/lib/librte_cryptodev/rte_crypto.h
> > @@ -266,8 +266,8 @@ rte_crypto_op_alloc(struct rte_mempool
> *mempool,
> > enum rte_crypto_op_type type)
> > * @param nb_ops Number of crypto operations to allocate
> > *
> > * @returns
> > - * - On success returns a valid rte_crypto_op structure
> > - * - On failure returns NULL
> > + * - 0 if no operations could be allocated
> > + * - nb_ops if the number of operations requested were allocated
> > */
> >
> My first thought was what's returned if some ops could be allocated, but
> not the requested number?
> Maybe instead:
> - nb_ops if the number of operations requested were allocated.
> - 0 if the requested number of ops are not available. None are allocated in
> this case.
Good clarification. Will send a v2 shortly.
Thanks,
Pablo
>
> > static inline unsigned
> > --
> > 2.9.4
[dpdk-dev] [PATCH v2] cryptodev: fix crypto op bulk alloc Doxygen
When calling rte_crypto_op_bulk_alloc, the function may
return either a 0, if not enough objects are available
in the mempool or the number of operations requested,
it there are enough available. However, the Doxygen comments
were not matching these two cases.
Fixes: c0f87eb5252b ("cryptodev: change burst API to be crypto op oriented")
Cc: sta...@dpdk.org
Signed-off-by: Pablo de Lara
---
Changes in v2:
- Reworded Doxygen comment for more clarification.
lib/librte_cryptodev/rte_crypto.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/librte_cryptodev/rte_crypto.h
b/lib/librte_cryptodev/rte_crypto.h
index 0908368..10fe080 100644
--- a/lib/librte_cryptodev/rte_crypto.h
+++ b/lib/librte_cryptodev/rte_crypto.h
@@ -266,8 +266,9 @@ rte_crypto_op_alloc(struct rte_mempool *mempool, enum
rte_crypto_op_type type)
* @param nb_ops Number of crypto operations to allocate
*
* @returns
- * - On success returns a valid rte_crypto_op structure
- * - On failure returns NULL
+ * - nb_ops if the number of operations requested were allocated.
+ * - 0 if the requested number of ops are not available.
+ * None are allocated in this case.
*/
static inline unsigned
--
2.9.4
Re: [dpdk-dev] [PATCH v2] cryptodev: fix crypto op bulk alloc Doxygen
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Thursday, July 27, 2017 5:06 PM
> To: Trahe, Fiona ; Doherty, Declan
>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo ;
> sta...@dpdk.org
> Subject: [PATCH v2] cryptodev: fix crypto op bulk alloc Doxygen
>
> When calling rte_crypto_op_bulk_alloc, the function may
> return either a 0, if not enough objects are available
> in the mempool or the number of operations requested,
> it there are enough available. However, the Doxygen comments
> were not matching these two cases.
>
> Fixes: c0f87eb5252b ("cryptodev: change burst API to be crypto op oriented")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Pablo de Lara
Acked-by: Fiona Trahe
Re: [dpdk-dev] [PATCH v2] cryptodev: fix crypto op bulk alloc Doxygen
> -Original Message-
> From: Trahe, Fiona
> Sent: Thursday, July 27, 2017 5:17 PM
> To: De Lara Guarch, Pablo ; Doherty,
> Declan
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH v2] cryptodev: fix crypto op bulk alloc Doxygen
>
>
>
> > -Original Message-
> > From: De Lara Guarch, Pablo
> > Sent: Thursday, July 27, 2017 5:06 PM
> > To: Trahe, Fiona ; Doherty, Declan
> >
> > Cc: dev@dpdk.org; De Lara Guarch, Pablo
> > ; sta...@dpdk.org
> > Subject: [PATCH v2] cryptodev: fix crypto op bulk alloc Doxygen
> >
> > When calling rte_crypto_op_bulk_alloc, the function may return either
> > a 0, if not enough objects are available in the mempool or the number
> > of operations requested, it there are enough available. However, the
> > Doxygen comments were not matching these two cases.
> >
> > Fixes: c0f87eb5252b ("cryptodev: change burst API to be crypto op
> > oriented")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Pablo de Lara
> Acked-by: Fiona Trahe
Applied to dpdk-next-crypto.
Pablo
Re: [dpdk-dev] [PATCH v2 0/4] cryptodev vdev changes for -rc2
On Wed, Jul 19, 2017 at 9:31 AM, De Lara Guarch, Pablo wrote: > > > > > -Original Message- > > From: Jan Blunck [mailto:jblu...@gmail.com] On Behalf Of Jan Blunck > > Sent: Wednesday, July 12, 2017 8:59 PM > > To: dev@dpdk.org > > Cc: Doherty, Declan ; De Lara Guarch, Pablo > > > > Subject: [PATCH v2 0/4] cryptodev vdev changes for -rc2 > > > > This series is a preparation to move the vdev bus out of librte_eal. For > > that > > the newly added cryptodev vdev functions need to change signature to not > > require the rte_vdev.h header. > > > > Changes since v1: > > - move params parsing into new header > > - make rte_cryptodev_vdev_pmd_init() static inline > > > > Jan Blunck (4): > > cryptodev: remove obsolete include > > cryptodev: move initialization > > cryptodev: rework PMD init to not require rte_vdev.h > > cryptodev: move parameter parsing to its own header > > > > lib/librte_cryptodev/Makefile| 1 + > > lib/librte_cryptodev/rte_cryptodev.c | 3 + > > lib/librte_cryptodev/rte_cryptodev.h | 1 - > > lib/librte_cryptodev/rte_cryptodev_pmd.c | 37 +- > > lib/librte_cryptodev/rte_cryptodev_vdev.h| 71 --- > > lib/librte_cryptodev/rte_cryptodev_vdev_params.h | 89 > > > > lib/librte_cryptodev/rte_cryptodev_version.map | 1 - > > 7 files changed, 122 insertions(+), 81 deletions(-) create mode 100644 > > lib/librte_cryptodev/rte_cryptodev_vdev_params.h > > > > -- > > 2.13.2 > > Hi Jan, > > Since there are some issues in this patchset and knowing that these changes > are required > for work to be done in 17.11 (vdev moving out of EAL), let's postpone this > for the next release, > as also there is no API breakage in this (correct me if I am wrong). Unexporting a function does require a soname change. So this is affecting ABI.
[dpdk-dev] [PATCH] Fix bash path in shebangs
From: Alan Somers "/bin/bash" is a Linuxism. "/usr/bin/env bash" is portable. Signed-off-by Alan Somers --- examples/performance-thread/l3fwd-thread/test.sh | 2 +- usertools/dpdk-setup.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/examples/performance-thread/l3fwd-thread/test.sh b/examples/performance-thread/l3fwd-thread/test.sh index b7718b622..eb1fe2dc2 100755 --- a/examples/performance-thread/l3fwd-thread/test.sh +++ b/examples/performance-thread/l3fwd-thread/test.sh @@ -1,4 +1,4 @@ -#!/bin/bash +#!/usr/bin/env bash case "$1" in diff --git a/usertools/dpdk-setup.sh b/usertools/dpdk-setup.sh index c4fec5a63..ebf36f830 100755 --- a/usertools/dpdk-setup.sh +++ b/usertools/dpdk-setup.sh @@ -1,4 +1,4 @@ -#! /bin/bash +#! /usr/bin/env bash # BSD LICENSE # -- 2.13.3
[dpdk-dev] [PATCH] Fix bash path in shebangs
From: Alan Somers "/bin/bash" is a Linuxism. "/usr/bin/env bash" is portable. Signed-off-by: Alan Somers --- examples/performance-thread/l3fwd-thread/test.sh | 2 +- usertools/dpdk-setup.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/examples/performance-thread/l3fwd-thread/test.sh b/examples/performance-thread/l3fwd-thread/test.sh index b7718b622..eb1fe2dc2 100755 --- a/examples/performance-thread/l3fwd-thread/test.sh +++ b/examples/performance-thread/l3fwd-thread/test.sh @@ -1,4 +1,4 @@ -#!/bin/bash +#!/usr/bin/env bash case "$1" in diff --git a/usertools/dpdk-setup.sh b/usertools/dpdk-setup.sh index c4fec5a63..ebf36f830 100755 --- a/usertools/dpdk-setup.sh +++ b/usertools/dpdk-setup.sh @@ -1,4 +1,4 @@ -#! /bin/bash +#! /usr/bin/env bash # BSD LICENSE # -- 2.13.3
Re: [dpdk-dev] [PATCH] net/mlx5: poll completion queue once per a call
> On Jul 27, 2017, at 4:12 AM, Sagi Grimberg wrote: > > >>> Yes I realize that, but can't the device still complete in a burst (of >>> unsuppressed completions)? I mean its not guaranteed that for every >>> txq_complete a signaled completion is pending right? What happens if >>> the device has inconsistent completion pacing? Can't the sw grow a >>> batch of completions if txq_complete will process a single completion >>> unconditionally? >> Speculation. First of all, device doesn't delay completion notifications for >> no >> reason. ASIC is not a SW running on top of a OS. > > I'm sorry but this statement is not correct. It might be correct in a > lab environment, but in practice, there are lots of things that can > affect the device timing. Disagree. [...] > Reviewed-by: Sagi Grimberg Thanks for ack! Yongseok
Re: [dpdk-dev] [PATCH] doc: add testpmd bonding mode 4 aggregators mode
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Daniel Mrzyglod > Sent: Thursday, July 27, 2017 2:41 PM > To: Mcnamara, John ; Doherty, Declan > > Cc: dev@dpdk.org; Mrzyglod, DanielX T > Subject: [dpdk-dev] [PATCH] doc: add testpmd bonding mode 4 aggregators mode > > Add testpmd commands for setting aggregators mode in mode 4 (IEEE802.3AD). > > Signed-off-by: Daniel Mrzyglod Acked-by: Jingjing Wu
Re: [dpdk-dev] [PATCH] net/i40e: fix dereferencing null pointer
> -Original Message-
> From: Kozak, KubaX
> Sent: Thursday, July 27, 2017 3:28 PM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; Jain, Deepak K ; Jastrzebski,
> MichalX K
> ; Kozak, KubaX ;
> sta...@dpdk.org
> Subject: [PATCH] net/i40e: fix dereferencing null pointer
>
> Add check if o_vlan_mask and i_vlan_mask are
> not a NULL pointer.
>
> Coverity issue: 143448
> Coverity issue: 143449
> Fixes: d37705068ee8 ("net/i40e: parse QinQ pattern")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Kuba Kozak
> ---
> drivers/net/i40e/i40e_flow.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c
> index 95af701..b92719a 100644
> --- a/drivers/net/i40e/i40e_flow.c
> +++ b/drivers/net/i40e/i40e_flow.c
> @@ -3719,8 +3719,10 @@ i40e_flow_parse_qinq_pattern(__rte_unused struct
> rte_eth_dev *dev,
> }
>
> /* Get filter specification */
> - if ((o_vlan_mask->tci == rte_cpu_to_be_16(I40E_TCI_MASK)) &&
> - (i_vlan_mask->tci == rte_cpu_to_be_16(I40E_TCI_MASK))) {
> + if ((o_vlan_mask != NULL) && (o_vlan_mask->tci ==
> + rte_cpu_to_be_16(I40E_TCI_MASK)) &&
> + (i_vlan_mask != NULL) &&
> + (i_vlan_mask->tci == rte_cpu_to_be_16(I40E_TCI_MASK))) {
> filter->outer_vlan = rte_be_to_cpu_16(o_vlan_spec->tci)
> & I40E_TCI_MASK;
> filter->inner_vlan = rte_be_to_cpu_16(i_vlan_spec->tci)
> --
Acked-by: Jingjing Wu
Thanks
[dpdk-dev] [PATCH v2] net/i40e: fix PF notify issue when VF not up
This patch modifies PF notify error to warning when not starting
up VF and modifies VF state to active when VF reset is completed.
Fixes: 4861cde46116 ("i40e: new poll mode driver")
Cc: sta...@dpdk.org
Signed-off-by: Xiaoyun Li
---
v2 changes:
* add VF state modification when VF reset is done.
---
drivers/net/i40e/i40e_pf.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
index b4cf57f..5d5d24a 100644
--- a/drivers/net/i40e/i40e_pf.c
+++ b/drivers/net/i40e/i40e_pf.c
@@ -152,22 +152,23 @@ i40e_pf_host_vf_reset(struct i40e_pf_vf *vf, bool
do_hw_reset)
val |= I40E_VPGEN_VFRTRIG_VFSWR_MASK;
I40E_WRITE_REG(hw, I40E_VPGEN_VFRTRIG(vf_id), val);
I40E_WRITE_FLUSH(hw);
- }
#define VFRESET_MAX_WAIT_CNT 100
- /* Wait until VF reset is done */
- for (i = 0; i < VFRESET_MAX_WAIT_CNT; i++) {
- rte_delay_us(10);
- val = I40E_READ_REG(hw, I40E_VPGEN_VFRSTAT(vf_id));
- if (val & I40E_VPGEN_VFRSTAT_VFRD_MASK)
- break;
- }
+ /* Wait until VF reset is done */
+ for (i = 0; i < VFRESET_MAX_WAIT_CNT; i++) {
+ rte_delay_us(10);
+ val = I40E_READ_REG(hw, I40E_VPGEN_VFRSTAT(vf_id));
+ if (val & I40E_VPGEN_VFRSTAT_VFRD_MASK) {
+ vf->state = I40E_VF_ACTIVE;
+ break;
+ }
+ }
- if (i >= VFRESET_MAX_WAIT_CNT) {
- PMD_DRV_LOG(ERR, "VF reset timeout");
- return -ETIMEDOUT;
+ if (i >= VFRESET_MAX_WAIT_CNT) {
+ PMD_DRV_LOG(ERR, "VF reset timeout");
+ return -ETIMEDOUT;
+ }
}
-
/* This is not first time to do reset, do cleanup job first */
if (vf->vsi) {
/* Disable queues */
@@ -267,8 +268,12 @@ i40e_pf_host_send_msg_to_vf(struct i40e_pf_vf *vf,
ret = i40e_aq_send_msg_to_vf(hw, abs_vf_id, opcode, retval,
msg, msglen, NULL);
if (ret) {
- PMD_INIT_LOG(ERR, "Fail to send message to VF, err %u",
-hw->aq.asq_last_status);
+ if (vf->state == I40E_VF_INACTIVE)
+ PMD_DRV_LOG(WARNING, "Warning! VF %u is inactive now!",
+ abs_vf_id);
+ else
+ PMD_INIT_LOG(ERR, "Fail to send message to VF, err %u",
+ hw->aq.asq_last_status);
}
return ret;
--
2.7.4
Re: [dpdk-dev] [PATCH v2] net/i40e: fix PF notify issue when VF not up
> -Original Message-
> From: Li, Xiaoyun
> Sent: Friday, July 28, 2017 7:40 PM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; Li, Xiaoyun ; sta...@dpdk.org
> Subject: [PATCH v2] net/i40e: fix PF notify issue when VF not up
>
> This patch modifies PF notify error to warning when not starting
> up VF and modifies VF state to active when VF reset is completed.
>
> Fixes: 4861cde46116 ("i40e: new poll mode driver")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiaoyun Li
> ---
> v2 changes:
> * add VF state modification when VF reset is done.
> ---
> drivers/net/i40e/i40e_pf.c | 33 +++--
> 1 file changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
> index b4cf57f..5d5d24a 100644
> --- a/drivers/net/i40e/i40e_pf.c
> +++ b/drivers/net/i40e/i40e_pf.c
> @@ -152,22 +152,23 @@ i40e_pf_host_vf_reset(struct i40e_pf_vf *vf, bool
> do_hw_reset)
> val |= I40E_VPGEN_VFRTRIG_VFSWR_MASK;
> I40E_WRITE_REG(hw, I40E_VPGEN_VFRTRIG(vf_id), val);
> I40E_WRITE_FLUSH(hw);
> - }
>
> #define VFRESET_MAX_WAIT_CNT 100
> - /* Wait until VF reset is done */
> - for (i = 0; i < VFRESET_MAX_WAIT_CNT; i++) {
> - rte_delay_us(10);
> - val = I40E_READ_REG(hw, I40E_VPGEN_VFRSTAT(vf_id));
> - if (val & I40E_VPGEN_VFRSTAT_VFRD_MASK)
> - break;
> - }
> + /* Wait until VF reset is done */
> + for (i = 0; i < VFRESET_MAX_WAIT_CNT; i++) {
> + rte_delay_us(10);
> + val = I40E_READ_REG(hw, I40E_VPGEN_VFRSTAT(vf_id));
> + if (val & I40E_VPGEN_VFRSTAT_VFRD_MASK) {
> + vf->state = I40E_VF_ACTIVE;
> + break;
> + }
> + }
>
> - if (i >= VFRESET_MAX_WAIT_CNT) {
> - PMD_DRV_LOG(ERR, "VF reset timeout");
> - return -ETIMEDOUT;
> + if (i >= VFRESET_MAX_WAIT_CNT) {
> + PMD_DRV_LOG(ERR, "VF reset timeout");
> + return -ETIMEDOUT;
> + }
It's much clearer to add "vf->state = I40E_VF_ACTIVE;" here but not above.
> }
> -
> /* This is not first time to do reset, do cleanup job first */
> if (vf->vsi) {
> /* Disable queues */
> @@ -267,8 +268,12 @@ i40e_pf_host_send_msg_to_vf(struct i40e_pf_vf *vf,
> ret = i40e_aq_send_msg_to_vf(hw, abs_vf_id, opcode, retval,
> msg, msglen, NULL);
> if (ret) {
> - PMD_INIT_LOG(ERR, "Fail to send message to VF, err %u",
> - hw->aq.asq_last_status);
> + if (vf->state == I40E_VF_INACTIVE)
> + PMD_DRV_LOG(WARNING, "Warning! VF %u is inactive now!",
> + abs_vf_id);
How about just don't send msg to inactive VF but not print warning?
> + else
> + PMD_INIT_LOG(ERR, "Fail to send message to VF, err %u",
> + hw->aq.asq_last_status);
> }
>
> return ret;
> --
> 2.7.4
