[dpdk-dev] [PATCH v2] app/testbbdev: fix sprintf with snprintf or strlcpy

[Pallantla Poornima]

sprintf function is not secure as it doesn't check the length of string.
More secure function snprintf and strlcpy is used.

Fixes: f714a18885 ("app/testbbdev: add test application for bbdev")
Cc: sta...@dpdk.org

Signed-off-by: Pallantla Poornima 
---
v2: Used strlcpy instead of snprintf as suggested.
---
 app/test-bbdev/test_bbdev.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/app/test-bbdev/test_bbdev.c b/app/test-bbdev/test_bbdev.c
index a914817bc..137c74cde 100644
--- a/app/test-bbdev/test_bbdev.c
+++ b/app/test-bbdev/test_bbdev.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include
+#include 
 
 #include "main.h"
 
@@ -788,14 +790,14 @@ test_bbdev_driver_init(void)
 
/* Initialize the maximum amount of devices */
do {
-   sprintf(name_tmp, "%s%i", "name_", num_devs);
+   snprintf(name_tmp, sizeof(name_tmp), "%s%i", "name_", num_devs);
dev2 = rte_bbdev_allocate(name_tmp);
TEST_ASSERT(dev2 != NULL,
"Failed to initialize bbdev driver");
++num_devs;
} while (num_devs < (RTE_BBDEV_MAX_DEVS - 1));
 
-   sprintf(name_tmp, "%s%i", "name_", num_devs);
+   snprintf(name_tmp, sizeof(name_tmp), "%s%i", "name_", num_devs);
dev2 = rte_bbdev_allocate(name_tmp);
TEST_ASSERT(dev2 == NULL, "Failed to initialize bbdev driver number %d "
"more drivers than RTE_BBDEV_MAX_DEVS: %d ", num_devs,
@@ -804,7 +806,7 @@ test_bbdev_driver_init(void)
num_devs--;
 
while (num_devs >= num_devs_tmp) {
-   sprintf(name_tmp, "%s%i", "name_", num_devs);
+   snprintf(name_tmp, sizeof(name_tmp), "%s%i", "name_", num_devs);
dev2 = rte_bbdev_get_named_dev(name_tmp);
TEST_ASSERT_SUCCESS(rte_bbdev_release(dev2),
"Failed to uninitialize bbdev driver %s ",
@@ -825,7 +827,7 @@ test_bbdev_driver_init(void)
TEST_ASSERT_FAIL(rte_bbdev_release(NULL),
"Failed to uninitialize bbdev driver with NULL bbdev");
 
-   sprintf(name_tmp, "%s", "invalid_name");
+   strlcpy(name_tmp, "invalid_name", sizeof(name_tmp));
dev2 = rte_bbdev_get_named_dev(name_tmp);
TEST_ASSERT_FAIL(rte_bbdev_release(dev2),
"Failed to uninitialize bbdev driver with invalid 
name");
-- 
2.17.2

Re: [dpdk-dev] [PATCH 2/2] net/ixgbe: add support of loopback for X540/X550

[Meunier, Julien (Nokia - FR/Paris-Saclay)]

Hi all,

Sorry for the delay. See my reply inline.

On 12/02/2019 07:37, Zhao1, Wei wrote:
> HI,  Meunier && qi
> 
> Is it possible to add these two function of ixgbe_setup_phy_autoneg_x540 and
> ixgbe_setup_phy_autoneg_x550 in a file out of base folder? We need to avoid
> change code in that, is that right? @qi
> And also, it seems these 2 function do not have much difference,
> can we use one instead of two function?(This point is not so important)

OK, no problem. I had some doubts when I modified these files.
So, I guess it's OK for you to have direct PHY operations (hw->phy.ops. 
[read|write]_reg) in ixgbe_rxtx.c ?


>>* Start Transmit and Receive Units.
>> @@ -5172,6 +5223,12 @@ ixgbe_dev_rxtx_start(struct rte_eth_dev *dev)
>>  if (dev->data->dev_conf.lpbk_mode != 0) {
>>  if (hw->mac.type == ixgbe_mac_82599EB)
>>  ixgbe_setup_loopback_link_82599(hw);
>> +else if (hw->mac.type == ixgbe_mac_X540)
>> +ixgbe_setup_loopback_link_x540(hw);
>> +else if (hw->mac.type == ixgbe_mac_X550 ||
>> + hw->mac.type == ixgbe_mac_X550EM_x ||
>> + hw->mac.type == ixgbe_mac_X550EM_a)
>> +ixgbe_setup_loopback_link_x550(hw);
> 
> The same, why do we have 2 branch for x540 and x550?
> 

I just wanted to respect the initial rule: 1 model = 1 function. But I 
can merge them in one function as it's the same mechanism in order to 
setup the loopback.

I will update a new patchset today.

Best regards,
Julien Meunier

Re: [dpdk-dev] [PATCH v2] test/pmd_perf: fix the way to drain the port

[Meunier, Julien (Nokia - FR/Paris-Saclay)]

Hi,

Sorry for the delay. Inline reply.

On 07/02/2019 13:28, Ferruh Yigit wrote:
> On 2/3/2019 7:42 PM, Julien Meunier wrote:
>> If the port has received less than ``pkt_per_port`` packets (for
>> example, the port has missed some packets), the test is in an infinite
>> loop.
>>
>> Instead of expecting a number of packet to receive, let the port to be
>> drained by itself. If no more packets are received, the test can
>> continue.
>>
>> Fixes: 002ade70e933 ("app/test: measure cycles per packet in Rx/Tx")
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Julien Meunier 
>> ---
>> v2:
>> * rename commit title
>> * fix nb_free display
>> ---
>>   test/test/test_pmd_perf.c | 8 
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/test/test/test_pmd_perf.c b/test/test/test_pmd_perf.c
>> index f5095c8..c7e2df3 100644
>> --- a/test/test/test_pmd_perf.c
>> +++ b/test/test/test_pmd_perf.c
>> @@ -493,16 +493,16 @@ main_loop(__rte_unused void *args)
>>   
>>  for (i = 0; i < conf->nb_ports; i++) {
>>  portid = conf->portlist[i];
>> -int nb_free = pkt_per_port;
>> +int nb_free = 0;
>>  do { /* dry out */
>>  nb_rx = rte_eth_rx_burst(portid, 0,
>>   pkts_burst, MAX_PKT_BURST);
>>  nb_tx = 0;
>>  while (nb_tx < nb_rx)
>>  rte_pktmbuf_free(pkts_burst[nb_tx++]);
>> -nb_free -= nb_rx;
>> -} while (nb_free != 0);
>> -printf("free %d mbuf left in port %u\n", pkt_per_port, portid);
>> +nb_free += nb_rx;
>> +} while (nb_rx != 0);
>> +printf("free %d mbuf left in port %u\n", nb_free, portid);
> 
> 
> In the test logic there is an expectation that 'pkt_per_port' packets will be
> received.
> We are losing that intention here with this update. What do you think updating
> the log to include it, like:
> "free %d (expected %d) mbuf left in port %u\n", nb_free, pkt_per_port, portid
> 

OK. But, after thinking, I should add a little timeout in order to drain 
the port during N cycles (like it was already done in the function 
poll_burst - timeout), just to be sure that all packets are dequeued.

I will upload a new patch today.

Best regards,
Julien Meunier

[dpdk-dev] [PATCH] net/bonding: fix reset active slave

[Hari Kumar Vemula]

test_alb_reply_from_client test fails due to incorrect active slave
array's index. This was due to invalid active slave count.

Count of internals->active_slave is not updated even when active slave
is deactivated.
Hence active slave count always keeps incrementing beyond the actual
active slaves.

Fix is to set the internals->active_slave to starting index 0 whenever
it exceeds the number of slaves in active slave list and also update
the active slave count during slave de-activation.

Fixes: e1110e977648 ("net/bonding: fix Rx slave fairness")
Cc: sta...@dpdk.org

Signed-off-by: Hari Kumar Vemula 
---
 drivers/net/bonding/rte_eth_bond_api.c | 6 ++
 drivers/net/bonding/rte_eth_bond_pmd.c | 6 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bonding/rte_eth_bond_api.c 
b/drivers/net/bonding/rte_eth_bond_api.c
index e5e146540..ac084c4fd 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -129,6 +129,12 @@ deactivate_slave(struct rte_eth_dev *eth_dev, uint16_t 
port_id)
RTE_ASSERT(active_count < RTE_DIM(internals->active_slaves));
internals->active_slave_count = active_count;
 
+   /* Resetting active_slave when reaches to max
+* no of slaves in active list
+*/
+   if (internals->active_slave >= active_count)
+   internals->active_slave = 0;
+
if (eth_dev->data->dev_started) {
if (internals->mode == BONDING_MODE_8023AD) {
bond_mode_8023ad_start(eth_dev);
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 23cec2549..319215c0b 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -84,7 +84,7 @@ bond_ethdev_rx_burst(void *queue, struct rte_mbuf **bufs, 
uint16_t nb_pkts)
active_slave = 0;
}
 
-   if (++internals->active_slave == slave_count)
+   if (++internals->active_slave >= slave_count)
internals->active_slave = 0;
return num_rx_total;
 }
@@ -288,7 +288,7 @@ bond_ethdev_rx_burst_8023ad_fast_queue(void *queue, struct 
rte_mbuf **bufs,
active_slave = 0;
}
 
-   if (++internals->active_slave == slave_count)
+   if (++internals->active_slave >= slave_count)
internals->active_slave = 0;
 
return num_rx_total;
@@ -474,7 +474,7 @@ bond_ethdev_rx_burst_8023ad(void *queue, struct rte_mbuf 
**bufs,
idx = 0;
}
 
-   if (++internals->active_slave == slave_count)
+   if (++internals->active_slave >= slave_count)
internals->active_slave = 0;
 
return num_rx_total;
-- 
2.17.2

Re: [dpdk-dev] [PATCH 0/6] introduce DMA memory mapping for external memory

[Burakov, Anatoly]

On 17-Feb-19 6:18 AM, Shahaf Shuler wrote:

Thursday, February 14, 2019 6:20 PM, Burakov, Anatoly:

Subject: Re: [dpdk-dev] [PATCH 0/6] introduce DMA memory mapping for
external memory

On 14-Feb-19 1:28 PM, Shahaf Shuler wrote:

Thursday, February 14, 2019 12:19 PM, Burakov, Anatoly:

Subject: Re: [dpdk-dev] [PATCH 0/6] introduce DMA memory mapping for
external memory

On 13-Feb-19 7:24 PM, Shahaf Shuler wrote:

Wednesday, February 13, 2019 1:43 PM, Alejandro Lucero:

Subject: Re: [dpdk-dev] [PATCH 0/6] introduce DMA memory mapping
for external memory



[...]



If we are going to force all to use the extmem, then there is no need w/

this API. we can have the PMDs to register when the memory is registered.

We can just drop the vfio_dma_map APIs and that's it.



Well, whether we needed it or not is not really my call, but what i can say is
that using extmem_register is _necessary_ if you're going to use the PMD's.
You're right, we could just map memory for DMA at register time - that
would save one API call to get the memory working. It makes it a bit weird
semantically, but i think we can live with that :)


This was not my suggestion 😊. I don't think the register API should do the 
mapping as well.
My thoughts were on one of the two options:
1. have the series I propose here, and enable the user to work with memory 
managed outside of DPDK. Either force the user to call rte_extmem_register 
before the mapping or devices which needs memory to be also registered in the 
DPDK system can fail the mapping.
2. not providing such option to application, and forcing applications to 
populate a socket w/ external memory.

I vote for #1.


I too think #1 is better - we want this to be a valid use case. Allowing 
such usage in the first place is already gracious enough - all we ask in 
return is one extra API call, to politely let DPDK know that this memory 
exists and is going to be used for DMA :)


Also, having the memory registered will also allow us to refuse mapping 
if it cannot be found in DPDK maps - if rte_virt2memseg returns NULL, 
that means extmem_register was not called. I.e. we can _enforce_ usage 
of extmem_register, which i believe is a good thing for usability.






--
Thanks,
Anatoly



--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] net/avf: enable admin queue interrupt

[Zhang, Qi Z]

> -Original Message-
> From: Zhao1, Wei
> Sent: Wednesday, February 13, 2019 4:54 PM
> To: dev@dpdk.org
> Cc: Wu, Jingjing ; Zhang, Qi Z ;
> Zhao1, Wei 
> Subject: [PATCH] net/avf: enable admin queue interrupt
> 
Change title to "enable CLEARPBA bit"

> There is need to enble CLEARPBA bit for ice NIC of A0/A1 version in order to
> enable admin queue interrupt in avf mode.
> If not, avf will not work.

Reword to

Enable CLEARPBA bit is required by ice NIC of A0/A1 version to
enable admin queue interrupt.
Also enable CLEARPBA bit does no impact on AVF behaviour when be
hosted by other devices, so we can make it as default.
> 
> Signed-off-by: Wei Zhao 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [dpdk-dev] [PATCH v2] test/pmd_perf: fix the way to drain the port

[Ferruh Yigit]

On 2/18/2019 11:25 AM, Meunier, Julien (Nokia - FR/Paris-Saclay) wrote:
> Hi,
> 
> Sorry for the delay. Inline reply.
> 
> On 07/02/2019 13:28, Ferruh Yigit wrote:
>> On 2/3/2019 7:42 PM, Julien Meunier wrote:
>>> If the port has received less than ``pkt_per_port`` packets (for
>>> example, the port has missed some packets), the test is in an infinite
>>> loop.
>>>
>>> Instead of expecting a number of packet to receive, let the port to be
>>> drained by itself. If no more packets are received, the test can
>>> continue.
>>>
>>> Fixes: 002ade70e933 ("app/test: measure cycles per packet in Rx/Tx")
>>> Cc: sta...@dpdk.org
>>>
>>> Signed-off-by: Julien Meunier 
>>> ---
>>> v2:
>>> * rename commit title
>>> * fix nb_free display
>>> ---
>>>   test/test/test_pmd_perf.c | 8 
>>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/test/test/test_pmd_perf.c b/test/test/test_pmd_perf.c
>>> index f5095c8..c7e2df3 100644
>>> --- a/test/test/test_pmd_perf.c
>>> +++ b/test/test/test_pmd_perf.c
>>> @@ -493,16 +493,16 @@ main_loop(__rte_unused void *args)
>>>   
>>> for (i = 0; i < conf->nb_ports; i++) {
>>> portid = conf->portlist[i];
>>> -   int nb_free = pkt_per_port;
>>> +   int nb_free = 0;
>>> do { /* dry out */
>>> nb_rx = rte_eth_rx_burst(portid, 0,
>>>  pkts_burst, MAX_PKT_BURST);
>>> nb_tx = 0;
>>> while (nb_tx < nb_rx)
>>> rte_pktmbuf_free(pkts_burst[nb_tx++]);
>>> -   nb_free -= nb_rx;
>>> -   } while (nb_free != 0);
>>> -   printf("free %d mbuf left in port %u\n", pkt_per_port, portid);
>>> +   nb_free += nb_rx;
>>> +   } while (nb_rx != 0);
>>> +   printf("free %d mbuf left in port %u\n", nb_free, portid);
>>
>>
>> In the test logic there is an expectation that 'pkt_per_port' packets will be
>> received.
>> We are losing that intention here with this update. What do you think 
>> updating
>> the log to include it, like:
>> "free %d (expected %d) mbuf left in port %u\n", nb_free, pkt_per_port, portid
>>
> 
> OK. But, after thinking, I should add a little timeout in order to drain 
> the port during N cycles (like it was already done in the function 
> poll_burst - timeout), just to be sure that all packets are dequeued.

Not sure if we need this, at this stage all packets should be in device Rx
queue, can rte_eth_rx_burst() return 0 when there are packets waiting in the 
queue?

Anyway, this is after measurement done, and to free to the packets, so adding a
timeout (retry) mechanism won't hurt if you prefer to add this.

Thanks,
ferruh

> 
> I will upload a new patch today.
> 
> Best regards,
> Julien Meunier
> 

[dpdk-dev] [PATCH] doc: deprecate KNI ethtool support

[Ferruh Yigit]

Remove KNI ethtool support.

Signed-off-by: Ferruh Yigit 
---
RFC Patch: https://patches.dpdk.org/patch/49025/
---
 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 1b4fcb7e6..0491eeea1 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -75,3 +75,11 @@ Deprecation Notices
 
 * crypto/aesni_mb: the minimum supported intel-ipsec-mb library version will be
   changed from 0.49.0 to 0.52.0.
+
+* kni: remove KNI ethtool support. To clarify, this is not to remove the KNI,
+  but only to remove ethtool support of it that is disabled by default and
+  can be enabled via ``CONFIG_RTE_KNI_KMOD_ETHTOOL`` config option.
+  Existing KNI ethtool implementation is only supported by ``igb`` & ``ixgbe``
+  drivers, by using a copy of kernel drivers in DPDK. This model can't be 
extend
+  to all drivers in DPDK and it is too much effort to maintain kernel modules 
in DPDK.
+  As a result users won't be able to use ``ethtool`` via ``igb`` & ``ixgbe`` 
anymore.
-- 
2.20.1

Re: [dpdk-dev] [RFC] kni: remove ethtool support

[Ferruh Yigit]

On 2/6/2019 1:12 PM, Igor Ryzhov wrote:
> Hi Ferruh,
> 
> What's the plan with this patch?

Hi Igor,

I just sent a deprecation notice for this:
https://patches.dpdk.org/patch/50347/

If the deprecation notice approved, requires 3 acks, note will go into 19.05
And later this patch can go in 19.08

Thanks,
ferruh

> 
> Best regards,
> Igor
> 
> On Sat, Jan 5, 2019 at 7:55 PM Igor Ryzhov  > wrote:
> 
> Hi Ferruh,
> 
> I answered in another thread.
> 
> Regarding this patch – I have no objections now.
> 
> Best regards,
> Igor
> 
> On Tue, Dec 18, 2018 at 9:17 PM Ferruh Yigit  > wrote:
> 
> On 12/18/2018 9:20 AM, Ferruh Yigit wrote:
> > On 12/18/2018 8:20 AM, Igor Ryzhov wrote:
> >> Hi Ferruh,
> >>
> >> Please, look at my patch http://patches.dpdk.org/patch/48454/ and
> consider
> >> rebasing your patch over mine.
> >
> > Sorry about that, yes I will check it today.
> 
> Hi Igor,
> 
> I put some comments on your patch.
> 
> As far as I can see it also has a target to remove current type of 
> ethtool
> support, so this RFC should not be a concern to you.
> All ethtool support can be removed, when you have an actual solution 
> for
> driver
> independent ethtool support only a little code needs to be added back.
> 
> Thanks,
> ferruh
> 
> >
> >>
> >> As we discussed with Stephen, KNI needs to supply ethtool_ops with
> >> .get_link function, to properly support link status.
> >> So we should save ethtool_ops and implement .get_link using 
> standard
> >> ethtool_op_get_link.
> >>
> >> Best regards,
> >> Igor
> >
> >
> 

Re: [dpdk-dev] [RFC 00/14] prefix network structures

[Ferruh Yigit]

On 2/13/2019 11:48 AM, Yigit, Ferruh wrote:
> On 12/27/2018 9:35 AM, Olivier Matz wrote:
>> Hi,
>>
>> On Fri, Dec 21, 2018 at 03:14:29PM +, Ferruh Yigit wrote:
>>> On 12/21/2018 2:38 PM, Wiles, Keith wrote:


> On Dec 20, 2018, at 5:48 PM, Stephen Hemminger 
>  wrote:
>
> On Thu, 20 Dec 2018 21:59:37 +
> Ferruh Yigit  wrote:
>
>> On 10/24/2018 9:18 AM, olivier.matz at 6wind.com (Olivier Matz) wrote:
>>> This RFC targets 19.02.
>>>
>>> The rte_net headers conflict with the libc headers, because
>>> some definitions are duplicated, sometimes with few differences.
>>> This was discussed in [1], and more recently at the techboard.
>>>
>>> Before sending the deprecation notice (target for this is 18.11),
>>> here is a draft that can be discussed.
>>>
>>> This RFC adds the rte_ (or RTE_) prefix to all structures, functions
>>> and defines in rte_net library. This is a big changeset, that will
>>> break the API of many functions, but not the ABI.
>>>
>>> One question I'm asking is how can we manage the transition.
>>> Initially, I hoped it was possible to have a compat layer during
>>> one release (supporting both prefixed and unprefixed names), but
>>> now that the patch is done, it seems the impact is too big, and
>>> impacts too many libraries.
>>>
>>> Few examples:
>>>  - rte_eth_macaddr_get/add/remove() use a (struct rte_ether_addr *)
>>>  - many rte_flow structures use the rte_ prefixed net structures
>>>  - the mac field of virtio_net structure is rte_ether_addr
>>>  - the first arg of rte_thash_load_v6_addrs is (struct rte_ipv6_hdr *)
>>>  ...
>>>
>>> Therefore, it is clear that doing this would break the compilation
>>> of many external applications.
>>>
>>> Another drawback we need to take in account: it will make the
>>> backport of patches more difficult, although this is something
>>> that could be tempered by a script.
>>>
>>> While it is obviously better to have a good namespace convention, 
>>> we need to identify the issues we have today before deciding it's
>>> worth doing the change.
>>>
>>> Comments?  
>>
>> Is there an consensus about the patchset? There was a decision on 
>> techboard to
>> go with this change (adding rte_ prefix) [1].
>>
>>
>> This is something that will affect DPDK consumers. Since many APIs are 
>> changing
>> most probably will break API compatibility for many libraries.
>>
>> Meanwhile the conflict with the libc headers mentioned a few times in 
>> the past,
>> this is something we need to fix.
>>
>> There are a few comments reluctant to this big modification, but what I
>> understand from Olivier's response both using BSD defines or having
>> compatibility headers in DPDK won't solve the problem completely.
>>
>> And assuming we will continue with this solution, another question is do 
>> we
>> still want to push in 19.02 scope? (And from process point of view I 
>> think a
>> deprecation notice is not merged for this change in 18.11 scope.)
>>
>> With the prediction of 19.05 will be big and already break API/ABI for 
>> some
>> libraries, can we push this into 19.05 as an early merge into repo?
>>
>> And I think this patch will affect LTS releases and will break auto 
>> backporting
>> for many fixes because it touches many places, so pushing this change 
>> even to
>> next LTS (19.11) can be an option.
>>
>>
>> Olivier, Thomas,
>>
>> What do you think about postponing this to 19.05 or even 19.11 ?
>>
>>
>>
>> [1]
>> https://mails.dpdk.org/archives/dev/2018-October/116695.html
>>
>>>
>>>
>>> Things that are missing in RFC:
>>> - test with FreeBSD
>>> - manually fix some indentation issues
>>>
>>>
>>> Olivier Matz (14):
>>>  net: add rte prefix to arp structures
>>>  net: add rte prefix to arp defines
>>>  net: add rte prefix to ether structures
>>>  net: add rte prefix to ether functions
>>>  net: add rte prefix to ether defines
>>>  net: add rte prefix to esp structure
>>>  net: add rte prefix to gre structure
>>>  net: add rte prefix to icmp structure
>>>  net: add rte prefix to icmp defines
>>>  net: add rte prefix to ip structure
>>>  net: add rte prefix to ip defines
>>>  net: add rte prefix to sctp structure
>>>  net: add rte prefix to tcp structure
>>>  net: add rte prefix to udp structure  
>>
>>
>
> Sigh. Another case where DPDK has to reinvent something because
> we can't figure out how to do dependent libraries correctly.
> I would have rather just using the existing Linux, BSD definitions
> and fixing the DPDK code.
>>
>>
>> It is not that simple. As I said in [1], there are st

Re: [dpdk-dev] [PATCH v2] net/ice: enable VLAN filter offloads support

[Zhang, Qi Z]

> -Original Message-
> From: Zhao1, Wei
> Sent: Wednesday, February 13, 2019 11:50 AM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Zhang, Qi Z ; Zhao1, Wei
> 
> Subject: [PATCH v2] net/ice: enable VLAN filter offloads support

I think this is a fix, since vlan filter is already be promised by 
ice_dev_info_get.

So add below fix line.
Fixes: 690175ee51bf ("net/ice: support getting device information")
> 
> There is need to check whether dev_conf.rxmode.offloads is set when start ice
> device, if one of the vlan related bits is set, for example
> DEV_RX_OFFLOAD_VLAN_FILTER and so on, sevice start process to enable this
> offloads request.

Some typo, reword to

  VLAN filter is required to be configured during dev_start according to 
dev_conf.rxmod.offloads
setting, so ice_vlan_offload_set is called to handle this.
> 
> Signed-off-by: Wei Zhao 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel with above changes.

Thanks
Qi

Re: [dpdk-dev] [PATCH v3] net/ice: faster bit check

[Zhang, Qi Z]

> -Original Message-
> From: Stillwell Jr, Paul M
> Sent: Saturday, February 16, 2019 2:13 AM
> To: Zhang, Qi Z 
> Cc: dev@dpdk.org; Brandeburg, Jesse ; Stillwell 
> Jr,
> Paul M 
> Subject: [PATCH v3] net/ice: faster bit check
> 
> From: Jesse Brandeburg 
> 
> Implement a slightly faster bit check, used for checking descriptors in the 
> hot
> path.
> 
> Signed-off-by: Jesse Brandeburg 
> Signed-off-by: Paul M Stillwell Jr 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [dpdk-dev] [RFC] kni: remove ethtool support

[Igor Ryzhov]

Hi Ferruh,

Thanks. Should I be a maintainer to ack the patch?

Best regards,
Igor

On Mon, Feb 18, 2019 at 3:33 PM Ferruh Yigit  wrote:

> On 2/6/2019 1:12 PM, Igor Ryzhov wrote:
> > Hi Ferruh,
> >
> > What's the plan with this patch?
>
> Hi Igor,
>
> I just sent a deprecation notice for this:
> https://patches.dpdk.org/patch/50347/
>
> If the deprecation notice approved, requires 3 acks, note will go into
> 19.05
> And later this patch can go in 19.08
>
> Thanks,
> ferruh
>
> >
> > Best regards,
> > Igor
> >
> > On Sat, Jan 5, 2019 at 7:55 PM Igor Ryzhov  > > wrote:
> >
> > Hi Ferruh,
> >
> > I answered in another thread.
> >
> > Regarding this patch – I have no objections now.
> >
> > Best regards,
> > Igor
> >
> > On Tue, Dec 18, 2018 at 9:17 PM Ferruh Yigit  > > wrote:
> >
> > On 12/18/2018 9:20 AM, Ferruh Yigit wrote:
> > > On 12/18/2018 8:20 AM, Igor Ryzhov wrote:
> > >> Hi Ferruh,
> > >>
> > >> Please, look at my patch http://patches.dpdk.org/patch/48454/
> and
> > consider
> > >> rebasing your patch over mine.
> > >
> > > Sorry about that, yes I will check it today.
> >
> > Hi Igor,
> >
> > I put some comments on your patch.
> >
> > As far as I can see it also has a target to remove current type
> of ethtool
> > support, so this RFC should not be a concern to you.
> > All ethtool support can be removed, when you have an actual
> solution for
> > driver
> > independent ethtool support only a little code needs to be added
> back.
> >
> > Thanks,
> > ferruh
> >
> > >
> > >>
> > >> As we discussed with Stephen, KNI needs to supply ethtool_ops
> with
> > >> .get_link function, to properly support link status.
> > >> So we should save ethtool_ops and implement .get_link using
> standard
> > >> ethtool_op_get_link.
> > >>
> > >> Best regards,
> > >> Igor
> > >
> > >
> >
>
>

Re: [dpdk-dev] [RFC] kni: remove ethtool support

[Ferruh Yigit]

On 2/18/2019 1:07 PM, Igor Ryzhov wrote:
> Hi Ferruh,
> 
> Thanks. Should I be a maintainer to ack the patch?

No, everyone can (n)ack a patch, though maintainers have more weight.

> 
> Best regards,
> Igor
> 
> On Mon, Feb 18, 2019 at 3:33 PM Ferruh Yigit  > wrote:
> 
> On 2/6/2019 1:12 PM, Igor Ryzhov wrote:
> > Hi Ferruh,
> >
> > What's the plan with this patch?
> 
> Hi Igor,
> 
> I just sent a deprecation notice for this:
> https://patches.dpdk.org/patch/50347/
> 
> If the deprecation notice approved, requires 3 acks, note will go into 
> 19.05
> And later this patch can go in 19.08
> 
> Thanks,
> ferruh
> 
> >
> > Best regards,
> > Igor
> >
> > On Sat, Jan 5, 2019 at 7:55 PM Igor Ryzhov  
> > >> wrote:
> >
> >     Hi Ferruh,
> >
> >     I answered in another thread.
> >
> >     Regarding this patch – I have no objections now.
> >
> >     Best regards,
> >     Igor
> >
> >     On Tue, Dec 18, 2018 at 9:17 PM Ferruh Yigit  
> >     >> 
> wrote:
> >
> >         On 12/18/2018 9:20 AM, Ferruh Yigit wrote:
> >         > On 12/18/2018 8:20 AM, Igor Ryzhov wrote:
> >         >> Hi Ferruh,
> >         >>
> >         >> Please, look at my patch 
> http://patches.dpdk.org/patch/48454/ and
> >         consider
> >         >> rebasing your patch over mine.
> >         >
> >         > Sorry about that, yes I will check it today.
> >
> >         Hi Igor,
> >
> >         I put some comments on your patch.
> >
> >         As far as I can see it also has a target to remove current type 
> of
> ethtool
> >         support, so this RFC should not be a concern to you.
> >         All ethtool support can be removed, when you have an actual
> solution for
> >         driver
> >         independent ethtool support only a little code needs to be 
> added back.
> >
> >         Thanks,
> >         ferruh
> >
> >         >
> >         >>
> >         >> As we discussed with Stephen, KNI needs to supply 
> ethtool_ops with
> >         >> .get_link function, to properly support link status.
> >         >> So we should save ethtool_ops and implement .get_link using
> standard
> >         >> ethtool_op_get_link.
> >         >>
> >         >> Best regards,
> >         >> Igor
> >         >
> >         >
> >
> 

Re: [dpdk-dev] [PATCH] doc: deprecate KNI ethtool support

[Neil Horman]

On Mon, Feb 18, 2019 at 12:30:02PM +, Ferruh Yigit wrote:
> Remove KNI ethtool support.
> 
> Signed-off-by: Ferruh Yigit 
> ---
> RFC Patch: https://patches.dpdk.org/patch/49025/
> ---
>  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 1b4fcb7e6..0491eeea1 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -75,3 +75,11 @@ Deprecation Notices
>  
>  * crypto/aesni_mb: the minimum supported intel-ipsec-mb library version will 
> be
>changed from 0.49.0 to 0.52.0.
> +
> +* kni: remove KNI ethtool support. To clarify, this is not to remove the KNI,
> +  but only to remove ethtool support of it that is disabled by default and
> +  can be enabled via ``CONFIG_RTE_KNI_KMOD_ETHTOOL`` config option.
> +  Existing KNI ethtool implementation is only supported by ``igb`` & 
> ``ixgbe``
> +  drivers, by using a copy of kernel drivers in DPDK. This model can't be 
> extend
> +  to all drivers in DPDK and it is too much effort to maintain kernel 
> modules in DPDK.
> +  As a result users won't be able to use ``ethtool`` via ``igb`` & ``ixgbe`` 
> anymore.
> -- 
> 2.20.1
> 
> 
Acked-by: Neil Horman 

Re: [dpdk-dev] [PATCH] doc: deprecate KNI ethtool support

[Igor Ryzhov]

Acked-by: Igor Ryzhov 

On Mon, Feb 18, 2019 at 3:30 PM Ferruh Yigit  wrote:

> Remove KNI ethtool support.
>
> Signed-off-by: Ferruh Yigit 
> ---
> RFC Patch: https://patches.dpdk.org/patch/49025/
> ---
>  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 1b4fcb7e6..0491eeea1 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -75,3 +75,11 @@ Deprecation Notices
>
>  * crypto/aesni_mb: the minimum supported intel-ipsec-mb library version
> will be
>changed from 0.49.0 to 0.52.0.
> +
> +* kni: remove KNI ethtool support. To clarify, this is not to remove the
> KNI,
> +  but only to remove ethtool support of it that is disabled by default and
> +  can be enabled via ``CONFIG_RTE_KNI_KMOD_ETHTOOL`` config option.
> +  Existing KNI ethtool implementation is only supported by ``igb`` &
> ``ixgbe``
> +  drivers, by using a copy of kernel drivers in DPDK. This model can't be
> extend
> +  to all drivers in DPDK and it is too much effort to maintain kernel
> modules in DPDK.
> +  As a result users won't be able to use ``ethtool`` via ``igb`` &
> ``ixgbe`` anymore.
> --
> 2.20.1
>
>

Re: [dpdk-dev] [PATCH] doc: deprecate KNI ethtool support

[Jerin Jacob Kollanukkaran]

On Mon, 2019-02-18 at 12:30 +, Ferruh Yigit wrote:
> Remove KNI ethtool support.
> 
> Signed-off-by: Ferruh Yigit 
> 

Acked-by: Jerin Jacob 

> ---
> RFC Patch: https://patches.dpdk.org/patch/49025/
> ---
>  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 1b4fcb7e6..0491eeea1 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -75,3 +75,11 @@ Deprecation Notices
>  
>  * crypto/aesni_mb: the minimum supported intel-ipsec-mb library
> version will be
>changed from 0.49.0 to 0.52.0.
> +
> +* kni: remove KNI ethtool support. To clarify, this is not to remove
> the KNI,
> +  but only to remove ethtool support of it that is disabled by
> default and
> +  can be enabled via ``CONFIG_RTE_KNI_KMOD_ETHTOOL`` config option.
> +  Existing KNI ethtool implementation is only supported by ``igb`` &
> ``ixgbe``
> +  drivers, by using a copy of kernel drivers in DPDK. This model
> can't be extend
> +  to all drivers in DPDK and it is too much effort to maintain
> kernel modules in DPDK.
> +  As a result users won't be able to use ``ethtool`` via ``igb`` &
> ``ixgbe`` anymore.

[dpdk-dev] [PATCH v2 1/2] test/distributor: flush with worker shutdown test fails

[Harman Kalra]

On restarting worker 0 after shutdown, packets handled by
worker 0 must be incremented only when a packet is received by
it.

Signed-off-by: Harman Kalra 
---
 test/test/test_distributor.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/test/test/test_distributor.c b/test/test/test_distributor.c
index 98919ec0c..a723254f7 100644
--- a/test/test/test_distributor.c
+++ b/test/test/test_distributor.c
@@ -373,7 +373,8 @@ handle_work_for_shutdown_test(void *arg)
id, buf, buf, num);
 
while (!quit) {
-   worker_stats[id].handled_packets++, count++;
+   worker_stats[id].handled_packets += num;
+   count += num;
rte_pktmbuf_free(pkt);
num = rte_distributor_get_pkt(d, id, buf, buf, num);
}
-- 
2.18.0

[dpdk-dev] [PATCH v2 2/2] distributor: imposing additional check on no of workers

[Harman Kalra]

no of workers should never exceed RTE_MAX_LCORE

Signed-off-by: Harman Kalra 
---
 lib/librte_distributor/rte_distributor.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/lib/librte_distributor/rte_distributor.c 
b/lib/librte_distributor/rte_distributor.c
index d50598377..043b8f3ae 100644
--- a/lib/librte_distributor/rte_distributor.c
+++ b/lib/librte_distributor/rte_distributor.c
@@ -595,6 +595,12 @@ rte_distributor_create_v1705(const char *name,
RTE_BUILD_BUG_ON((sizeof(*d) & RTE_CACHE_LINE_MASK) != 0);
RTE_BUILD_BUG_ON((RTE_DISTRIB_MAX_WORKERS & 7) != 0);
 
+   if (name == NULL || num_workers >=
+   (unsigned int)RTE_MIN(RTE_DISTRIB_MAX_WORKERS, RTE_MAX_LCORE)) {
+   rte_errno = EINVAL;
+   return NULL;
+   }
+
if (alg_type == RTE_DIST_ALG_SINGLE) {
d = malloc(sizeof(struct rte_distributor));
if (d == NULL) {
@@ -612,11 +618,6 @@ rte_distributor_create_v1705(const char *name,
return d;
}
 
-   if (name == NULL || num_workers >= RTE_DISTRIB_MAX_WORKERS) {
-   rte_errno = EINVAL;
-   return NULL;
-   }
-
snprintf(mz_name, sizeof(mz_name), RTE_DISTRIB_PREFIX"%s", name);
mz = rte_memzone_reserve(mz_name, sizeof(*d), socket_id, NO_FLAGS);
if (mz == NULL) {
-- 
2.18.0

Re: [dpdk-dev] [PATCH 2/2] net/bonding: avoid the next active slave going out of bound

[Ferruh Yigit]

On 2/11/2019 10:25 AM, Parthasarathy, JananeeX M wrote:
> Hi
> 
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Chas Williams
>> Sent: Saturday, February 09, 2019 6:47 PM
>> To: Hyong Youb Kim ; Yigit, Ferruh
>> ; Doherty, Declan ; Chas
>> Williams 
>> Cc: dev@dpdk.org; sta...@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 2/2] net/bonding: avoid the next active slave
>> going out of bound
>>
>>
>>
>> On 1/10/19 5:22 AM, Hyong Youb Kim wrote:
>>> For bonding modes like broadcast that use bond_ethdev_rx_burst(), it
>>> is fairly easy to produce a crash simply by bringing a slave port's
>>> link down. When slave links go down, the driver on one thread reduces
>>> active_slave_count via the LSC callback and deactivate_slave(). At the
>>> same time, bond_ethdev_rx_burst() running on a forwarding thread may
>>> increment active_slave (next active slave) beyond active_slave_count.
>>> Here is a typical sequence of events.
>>>
>>> At time 0:
>>> active_slave_count = 3
>>> active_slave = 2
>>>
>>> At time 1:
>>> A slave link goes down.
>>> Thread 0 (main) reduces active_slave_count to 2.
>>>
>>> At time 2:
>>> Thread 1 (forwarding) executes bond_ethdev_rx_burst().
>>> - Reads active_slave_count = 2.
>>> - Increments active_slave at the end to 3.
>>>
>>>  From this point on, everytime bond_ethdev_rx_burst() runs,
>>> active_slave increments by one, eventually going well out of bound of
>>> the active_slaves array and causing a crash.
>>>
>>> Make the rx burst function to first check that active_slave is within
>>> bound. If not, reset it to 0 to avoid out-of-range array access.
>>>
>>> Fixes: e1110e977648 ("net/bonding: fix Rx slave fairness")
>>> Cc: sta...@dpdk.org
>>>
>>> Signed-off-by: Hyong Youb Kim 
>>
>> Acked-by: Chas Williams 
>>
>>> ---
>>>   drivers/net/bonding/rte_eth_bond_pmd.c | 14 ++
>>>   1 file changed, 14 insertions(+)
>>>
>>> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
>>> b/drivers/net/bonding/rte_eth_bond_pmd.c
>>> index daf2440cd..bc2405e54 100644
>>> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
>>> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
>>> @@ -68,6 +68,15 @@ bond_ethdev_rx_burst(void *queue, struct rte_mbuf
>> **bufs, uint16_t nb_pkts)
>>> internals = bd_rx_q->dev_private;
>>> slave_count = internals->active_slave_count;
>>> active_slave = internals->active_slave;
>>> +   /*
>>> +* Reset the active slave index, in case active_slave goes out
>>> +* of bound.  It can hapen when slave links go down, and
>>> +* another thread (LSC callback) shrinks the slave count.
>>> +*/
>>> +   if (active_slave >= slave_count) {
>>> +   internals->active_slave = 0;
>>> +   active_slave = 0;
>>> +   }
> 
> Instead of introducing new conditions again at the top of functions, it would 
> be better to check greater than, equal to >= instead of the equal to  in 
> below condition.
> if (++internals->active_slave == slave_count)
> internals->active_slave = 0;
> 
> Thereby we can reduce the multiple if conditions and still ensure 
> internals->active_slave points to correct index always.
> 
>>>
>>> for (i = 0; i < slave_count && nb_pkts; i++) {
>>> uint16_t num_rx_slave;
>>> @@ -273,6 +282,11 @@ bond_ethdev_rx_burst_8023ad_fast_queue(void
>> *queue, struct rte_mbuf **bufs,
>>> active_slave = internals->active_slave;
>>> memcpy(slaves, internals->active_slaves,
>>> sizeof(internals->active_slaves[0]) * slave_count);
>>> +   /* active_slave may go out of bound. See bond_ethdev_rx_burst() */
>>> +   if (active_slave >= slave_count) {
>>> +   internals->active_slave = 0;
>>> +   active_slave = 0;
>>> +   }
> 
> Same as above comment would be better.
>>>
>>> for (i = 0; i < slave_count && nb_pkts; i++) {
>>> uint16_t num_rx_slave;
>>>
> 
> It would be better to check the internals->active_slave during 
> deactivate_slave() as well in rte_eth_bond_api.c.
> Since slave counts would be decremented during de-activation and resetting 
> here appropriately would be better.
> 
> Regards
> M.P.Jananee


I don't see this comment on the patchwork, can you double check if your comment
hit the mailing list?

Re: [dpdk-dev] [dpdk-stable] [PATCH] app/testpmd: fix crash when doing port info of vdev

[Ferruh Yigit]

On 2/16/2019 1:36 AM, Stephen Hemminger wrote:
> From: Stephen Hemminger 
> 
> Noticed a SEGV in testpmd doing:
>  > show port info 1
> on Hyper-V with failsafe/tap PMD.
> 
> A vdev may not have an associated device (i.e NULL) and therefore
> testpmd should skip devargs in that case.
> 
> Fixes: cf72ed09181b ("app/testpmd: display devargs in port info output")
> Signed-off-by: Stephen Hemminger 
> ---
>  app/test-pmd/config.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> index b9e5dd923b0f..38708db943d2 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -415,7 +415,8 @@ port_infos_display(portid_t port_id)
>   rte_eth_dev_get_name_by_port(port_id, name);
>   printf("\nDevice name: %s", name);
>   printf("\nDriver name: %s", dev_info.driver_name);
> - if (dev_info.device->devargs && dev_info.device->devargs->args)
> + if (dev_info.device && dev_info.device->devargs &&
> + dev_info.device->devargs->args)

This means 'eth_dev->device' is NULL. Why the 'device' is NULL for eth_dev?
Is there anything to fix in the PMD?

>   printf("\nDevargs: %s", dev_info.device->devargs->args);
>   printf("\nConnect to socket: %u", port->socket_id);
>  
> 

Re: [dpdk-dev] [dpdk-stable] [PATCH v3] mem: Fix anonymous mapping on Power9.

[Thomas Monjalon]

Hi,

Long time no talk about the IBM Power support status.

16/11/2018 18:35, David Wilder:
> --- a/doc/guides/rel_notes/release_18_11.rst
> +++ b/doc/guides/rel_notes/release_18_11.rst
> +* IBM Power8 is not supported by this release of DPDK. IBM Power9 is 
> supported.

The config file is defconfig_ppc_64-power8-linuxapp-gcc.
Given that only Power9 is supported, should we rename it?

Is there more changes required to make Power9 working with the latest DPDK?

Re: [dpdk-dev] [dpdk-stable] [PATCH v2] net/bonding: fix slave tx burst for mode 4

[Ferruh Yigit]

On 2/14/2019 7:09 PM, Chas Williams wrote:
> From: Chas Williams 
> 
> The tx burst routine always needs to check for pending LACPDUs
> and send them if available. Do this first to prioritize the
> control traffic.  We can still early exit, before calculating
> the distribution slaves, if there isn't any data packets.
> 
> Fixes: 09150784a776 ("net/bonding: burst mode hash calculation")
> Cc: sta...@dpdk.org
> Reported-by: Hui Zhao 
> Cc: Yunjian Wang 
> Signed-off-by: Chas Williams 

Applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [PATCH] net/bonding: fix reset active slave

[Radu Nicolau]

On 2/18/2019 11:59 AM, Hari Kumar Vemula wrote:

test_alb_reply_from_client test fails due to incorrect active slave
array's index. This was due to invalid active slave count.

Count of internals->active_slave is not updated even when active slave
is deactivated.
Hence active slave count always keeps incrementing beyond the actual
active slaves.

Fix is to set the internals->active_slave to starting index 0 whenever
it exceeds the number of slaves in active slave list and also update
the active slave count during slave de-activation.

Fixes: e1110e977648 ("net/bonding: fix Rx slave fairness")
Cc: sta...@dpdk.org

Signed-off-by: Hari Kumar Vemula 
---

Acked-by: Radu Nicolau >

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bonding: fix invalid link status

[Ferruh Yigit]

On 2/14/2019 7:11 PM, Chas Williams wrote:
> From: Chas Williams 
> 
> Copying the link properties of the first slave added may copy an
> invalid link status. The speed and duplex of the slave may not
> be known at this time. Delay setting the properties until the
> first slave reports as link up. Note that we are still ignoring
> an error from link_properties_valid. For some bonding modes,
> 802.3ad, we should not activate the slave if it does not have
> matching link properties.
> 
> Fixes: a45b288ef21a ("bond: support link status polling")
> Cc: sta...@dpdk.org
> Signed-off-by: Chas Williams 

Applied to dpdk-next-net/master, thanks.

[dpdk-dev] [PATCH 2/4] ipsec-secgw: add test scripts for aes ctr

[Fan Zhang]

This patch adds the functional test scripts to ipsec-secgw
sample application for both transport and tunnel working
mode.

Updated a bit on common_defs to use "mktemp" instead of "tempfile"
as Fedora does not like the command.

Signed-off-by: Fan Zhang 
---
 examples/ipsec-secgw/test/common_defs.sh   |  4 +-
 examples/ipsec-secgw/test/run_test.sh  | 10 +++-
 .../test/trs_aesctr_sha1_common_defs.sh| 69 +
 examples/ipsec-secgw/test/trs_aesctr_sha1_defs.sh  | 67 +
 .../test/trs_aesctr_sha1_esn_atom_defs.sh  |  5 ++
 .../ipsec-secgw/test/trs_aesctr_sha1_esn_defs.sh   | 66 
 .../ipsec-secgw/test/trs_aesctr_sha1_old_defs.sh   |  5 ++
 .../test/tun_aesctr_sha1_common_defs.sh| 68 +
 examples/ipsec-secgw/test/tun_aesctr_sha1_defs.sh  | 70 ++
 .../test/tun_aesctr_sha1_esn_atom_defs.sh  |  5 ++
 .../ipsec-secgw/test/tun_aesctr_sha1_esn_defs.sh   | 70 ++
 .../ipsec-secgw/test/tun_aesctr_sha1_old_defs.sh   |  5 ++
 12 files changed, 441 insertions(+), 3 deletions(-)
 create mode 100644 examples/ipsec-secgw/test/trs_aesctr_sha1_common_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesctr_sha1_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesctr_sha1_esn_atom_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesctr_sha1_esn_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesctr_sha1_old_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesctr_sha1_common_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesctr_sha1_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesctr_sha1_esn_atom_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesctr_sha1_esn_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesctr_sha1_old_defs.sh

diff --git a/examples/ipsec-secgw/test/common_defs.sh 
b/examples/ipsec-secgw/test/common_defs.sh
index 1ed31f89f..ea17cf9fd 100644
--- a/examples/ipsec-secgw/test/common_defs.sh
+++ b/examples/ipsec-secgw/test/common_defs.sh
@@ -53,7 +53,7 @@ SGW_CMD_EAL_PRM="--lcores=${SGW_LCORE} -n 4 ${ETH_DEV}"
 SGW_CMD_CFG="(0,0,${SGW_LCORE}),(1,0,${SGW_LCORE})"
 SGW_CMD_PRM="-p 0x3 -u 1 -P --config=\"${SGW_CMD_CFG}\""
 
-SGW_CFG_FILE=$(tempfile)
+SGW_CFG_FILE=$(mktemp)
 
 # configure local host/ifaces
 config_local_iface()
@@ -129,7 +129,7 @@ config6_iface()
 #start ipsec-secgw
 secgw_start()
 {
-   SGW_EXEC_FILE=$(tempfile)
+   SGW_EXEC_FILE=$(mktemp)
cat < ${SGW_EXEC_FILE}
 ${SGW_PATH} ${SGW_CMD_EAL_PRM} ${CRYPTO_DEV} \
 --vdev="net_tap0,mac=fixed" \
diff --git a/examples/ipsec-secgw/test/run_test.sh 
b/examples/ipsec-secgw/test/run_test.sh
index 6dc0ce54e..435de5da6 100644
--- a/examples/ipsec-secgw/test/run_test.sh
+++ b/examples/ipsec-secgw/test/run_test.sh
@@ -32,7 +32,15 @@ trs_aesgcm_esn_atom \
 tun_aescbc_sha1_old \
 tun_aesgcm_old \
 trs_aescbc_sha1_old \
-trs_aesgcm_old"
+trs_aesgcm_old \
+tun_aesctr_sha1 \
+tun_aesctr_sha1_esn \
+tun_aesctr_sha1_esn_atom \
+tun_aesctr_sha1_old \
+trs_aesctr_sha1 \
+trs_aesctr_sha1_esn \
+trs_aesctr_sha1_esn_atom \
+trs_aesctr_sha1_old"
 
 DIR=`dirname $0`
 
diff --git a/examples/ipsec-secgw/test/trs_aesctr_sha1_common_defs.sh 
b/examples/ipsec-secgw/test/trs_aesctr_sha1_common_defs.sh
new file mode 100644
index 0..9c213e3cc
--- /dev/null
+++ b/examples/ipsec-secgw/test/trs_aesctr_sha1_common_defs.sh
@@ -0,0 +1,69 @@
+#! /bin/bash
+
+CRYPTO_DEV=${CRYPTO_DEV:-'--vdev="crypto_aesni_mb0"'}
+
+#generate cfg file for ipsec-secgw
+config_secgw()
+{
+   cat < ${SGW_CFG_FILE}
+#SP in IPv4 rules
+sp ipv4 in esp protect 7 pri 2 src ${REMOTE_IPV4}/32 dst ${LOCAL_IPV4}/32 \
+sport 0:65535 dport 0:65535
+sp ipv4 in esp bypass pri 1 sport 0:65535 dport 0:65535
+
+#SP out IPv4 rules
+sp ipv4 out esp protect 7 pri 2 src ${LOCAL_IPV4}/32 dst ${REMOTE_IPV4}/32 \
+sport 0:65535 dport 0:65535
+sp ipv4 out esp bypass pri 1 sport 0:65535 dport 0:65535
+
+#sp in IPv6 rules
+sp ipv6 in esp protect 9 pri 2 src ${REMOTE_IPV6}/128 dst ${LOCAL_IPV6}/128 \
+sport 0:65535 dport 0:65535
+sp ipv6 in esp bypass pri 1 sport 0:65535 dport 0:65535
+
+#SP out IPv6 rules
+sp ipv6 out esp protect 9 pri 2 src ${LOCAL_IPV6}/128 dst ${REMOTE_IPV6}/128 \
+sport 0:65535 dport 0:65535
+sp ipv6 out esp bypass pri 1 sport 0:65535 dport 0:65535
+
+#SA in rules
+sa in 7 cipher_algo aes-128-ctr \
+cipher_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+auth_algo sha1-hmac \
+auth_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+mode transport
+
+sa in 9 cipher_algo aes-128-ctr \
+cipher_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+auth_algo sha1-hmac \
+auth_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+mode transport
+
+#SA out rules
+sa out 7 cipher_algo aes-128-ctr \
+cipher_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+auth_algo sha

[dpdk-dev] [PATCH 3/4] ipsec: add 3DES-CBC algorithm support

[Fan Zhang]

This patch adds triple-des CBC mode cipher algorithm to ipsec
library.

Signed-off-by: Fan Zhang 
---
 lib/librte_ipsec/sa.c | 10 ++
 lib/librte_ipsec/sa.h |  6 ++
 2 files changed, 16 insertions(+)

diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
index e34dd320a..5c59c4b67 100644
--- a/lib/librte_ipsec/sa.c
+++ b/lib/librte_ipsec/sa.c
@@ -307,6 +307,13 @@ esp_sa_init(struct rte_ipsec_sa *sa, const struct 
rte_ipsec_sa_prm *prm,
sa->algo_type = ALGO_TYPE_AES_CTR;
break;
 
+   case RTE_CRYPTO_CIPHER_3DES_CBC:
+   /* RFC 1851 */
+   sa->pad_align = IPSEC_PAD_3DES_CBC;
+   sa->iv_len = IPSEC_3DES_IV_SIZE;
+   sa->algo_type = ALGO_TYPE_3DES;
+   break;
+
default:
return -EINVAL;
}
@@ -512,6 +519,8 @@ esp_outb_cop_prepare(struct rte_crypto_op *cop,
sa->iv_ofs);
aes_ctr_cnt_blk_fill(ctr, ivp[0], sa->salt);
break;
+   case ALGO_TYPE_3DES:
+   /* Cipher-Auth (3DES-CBC *) case */
case ALGO_TYPE_NULL:
/* NULL case */
sop->cipher.data.offset = sa->ctp.cipher.offset + hlen;
@@ -873,6 +882,7 @@ esp_inb_tun_cop_prepare(struct rte_crypto_op *cop,
aead_gcm_iv_fill(gcm, ivp[0], sa->salt);
break;
case ALGO_TYPE_AES_CBC:
+   case ALGO_TYPE_3DES:
sop->cipher.data.offset = pofs + sa->ctp.cipher.offset;
sop->cipher.data.length = clen;
sop->auth.data.offset = pofs + sa->ctp.auth.offset;
diff --git a/lib/librte_ipsec/sa.h b/lib/librte_ipsec/sa.h
index 12c061ee6..8398748d1 100644
--- a/lib/librte_ipsec/sa.h
+++ b/lib/librte_ipsec/sa.h
@@ -14,6 +14,7 @@
 /* padding alignment for different algorithms */
 enum {
IPSEC_PAD_DEFAULT = 4,
+   IPSEC_PAD_3DES_CBC = IPSEC_PAD_DEFAULT,
IPSEC_PAD_AES_CBC = IPSEC_MAX_IV_SIZE,
IPSEC_PAD_AES_CTR = IPSEC_PAD_DEFAULT,
IPSEC_PAD_AES_GCM = IPSEC_PAD_DEFAULT,
@@ -24,6 +25,10 @@ enum {
 enum {
IPSEC_IV_SIZE_DEFAULT = IPSEC_MAX_IV_SIZE,
IPSEC_AES_CTR_IV_SIZE = sizeof(uint64_t),
+   /* TripleDES supports IV size of 32bits or 64bits but he library
+* only supports 64bits.
+*/
+   IPSEC_3DES_IV_SIZE = sizeof(uint64_t),
 };
 
 /* these definitions probably has to be in rte_crypto_sym.h */
@@ -57,6 +62,7 @@ struct replay_sqn {
 /*IPSEC SA supported algorithms */
 enum sa_algo_type  {
ALGO_TYPE_NULL = 0,
+   ALGO_TYPE_3DES,
ALGO_TYPE_AES_CBC,
ALGO_TYPE_AES_CTR,
ALGO_TYPE_AES_GCM,
-- 
2.14.5

[dpdk-dev] [PATCH 1/4] ipsec: add AES-CTR algorithm support

[Fan Zhang]

This patch adds AES-CTR cipher algorithm support to ipsec
library.

Signed-off-by: Fan Zhang 
---
 lib/librte_ipsec/crypto.h |  17 ++
 lib/librte_ipsec/sa.c | 133 ++
 lib/librte_ipsec/sa.h |  18 +++
 3 files changed, 147 insertions(+), 21 deletions(-)

diff --git a/lib/librte_ipsec/crypto.h b/lib/librte_ipsec/crypto.h
index b5f264831..4f551e39c 100644
--- a/lib/librte_ipsec/crypto.h
+++ b/lib/librte_ipsec/crypto.h
@@ -11,6 +11,16 @@
  * by ipsec library.
  */
 
+/*
+ * AES-CTR counter block format.
+ */
+
+struct aesctr_cnt_blk {
+   uint32_t nonce;
+   uint64_t iv;
+   uint32_t cnt;
+} __attribute__((packed));
+
  /*
   * AES-GCM devices have some specific requirements for IV and AAD formats.
   * Ideally that to be done by the driver itself.
@@ -41,6 +51,13 @@ struct gcm_esph_iv {
uint64_t iv;
 } __attribute__((packed));
 
+static inline void
+aes_ctr_cnt_blk_fill(struct aesctr_cnt_blk *ctr, uint64_t iv, uint32_t nonce)
+{
+   ctr->nonce = nonce;
+   ctr->iv = iv;
+   ctr->cnt = rte_cpu_to_be_32(1);
+}
 
 static inline void
 aead_gcm_iv_fill(struct aead_gcm_iv *gcm, uint64_t iv, uint32_t salt)
diff --git a/lib/librte_ipsec/sa.c b/lib/librte_ipsec/sa.c
index 5f55c2a4e..e34dd320a 100644
--- a/lib/librte_ipsec/sa.c
+++ b/lib/librte_ipsec/sa.c
@@ -219,18 +219,28 @@ esp_inb_tun_init(struct rte_ipsec_sa *sa, const struct 
rte_ipsec_sa_prm *prm)
 static void
 esp_outb_init(struct rte_ipsec_sa *sa, uint32_t hlen)
 {
+   uint8_t algo_type;
+
sa->sqn.outb.raw = 1;
 
/* these params may differ with new algorithms support */
sa->ctp.auth.offset = hlen;
sa->ctp.auth.length = sizeof(struct esp_hdr) + sa->iv_len + sa->sqh_len;
-   if (sa->aad_len != 0) {
+
+   algo_type = sa->algo_type;
+
+   switch (algo_type) {
+   case ALGO_TYPE_AES_GCM:
+   case ALGO_TYPE_AES_CTR:
+   case ALGO_TYPE_NULL:
sa->ctp.cipher.offset = hlen + sizeof(struct esp_hdr) +
sa->iv_len;
sa->ctp.cipher.length = 0;
-   } else {
+   break;
+   case ALGO_TYPE_AES_CBC:
sa->ctp.cipher.offset = sa->hdr_len + sizeof(struct esp_hdr);
sa->ctp.cipher.length = sa->iv_len;
+   break;
}
 }
 
@@ -259,26 +269,47 @@ esp_sa_init(struct rte_ipsec_sa *sa, const struct 
rte_ipsec_sa_prm *prm,
RTE_IPSEC_SATP_MODE_MASK;
 
if (cxf->aead != NULL) {
-   /* RFC 4106 */
-   if (cxf->aead->algo != RTE_CRYPTO_AEAD_AES_GCM)
+   switch (cxf->aead->algo) {
+   case RTE_CRYPTO_AEAD_AES_GCM:
+   /* RFC 4106 */
+   sa->aad_len = sizeof(struct aead_gcm_aad);
+   sa->icv_len = cxf->aead->digest_length;
+   sa->iv_ofs = cxf->aead->iv.offset;
+   sa->iv_len = sizeof(uint64_t);
+   sa->pad_align = IPSEC_PAD_AES_GCM;
+   sa->algo_type = ALGO_TYPE_AES_GCM;
+   break;
+   default:
return -EINVAL;
-   sa->aad_len = sizeof(struct aead_gcm_aad);
-   sa->icv_len = cxf->aead->digest_length;
-   sa->iv_ofs = cxf->aead->iv.offset;
-   sa->iv_len = sizeof(uint64_t);
-   sa->pad_align = IPSEC_PAD_AES_GCM;
+   }
} else {
sa->icv_len = cxf->auth->digest_length;
sa->iv_ofs = cxf->cipher->iv.offset;
sa->sqh_len = IS_ESN(sa) ? sizeof(uint32_t) : 0;
-   if (cxf->cipher->algo == RTE_CRYPTO_CIPHER_NULL) {
+
+   switch (cxf->cipher->algo) {
+   case RTE_CRYPTO_CIPHER_NULL:
sa->pad_align = IPSEC_PAD_NULL;
sa->iv_len = 0;
-   } else if (cxf->cipher->algo == RTE_CRYPTO_CIPHER_AES_CBC) {
+   sa->algo_type = ALGO_TYPE_NULL;
+   break;
+
+   case RTE_CRYPTO_CIPHER_AES_CBC:
sa->pad_align = IPSEC_PAD_AES_CBC;
sa->iv_len = IPSEC_MAX_IV_SIZE;
-   } else
+   sa->algo_type = ALGO_TYPE_AES_CBC;
+   break;
+
+   case RTE_CRYPTO_CIPHER_AES_CTR:
+   /* RFC 3686 */
+   sa->pad_align = IPSEC_PAD_AES_CTR;
+   sa->iv_len = IPSEC_AES_CTR_IV_SIZE;
+   sa->algo_type = ALGO_TYPE_AES_CTR;
+   break;
+
+   default:
return -EINVAL;
+   }
}
 
sa->udata = prm->userdata;
@@ -438,12 +469,15 @@ esp_outb_cop_prepare(struct rte_crypto_op *cop,
 {
struct rte_crypto_sym_op *sop;
struct aead_gcm_iv *gcm;
+   struct aesctr_cnt_blk

[dpdk-dev] [PATCH 0/4] ipsec: add AES-CTR and 3DES-CBC support

[Fan Zhang]

This patchset adds the AES-CTR and 3DES-CBC cipher algorithms
support to ipsec library. The test scripts for ipsec-secgw
sample application are added too.

Fan Zhang (4):
  ipsec: add AES-CTR algorithm support
  ipsec-secgw: add test scripts for aes ctr
  ipsec: add 3DES-CBC algorithm support
  ipsec-secgw: add 3des test files

 examples/ipsec-secgw/test/common_defs.sh   |   4 +-
 examples/ipsec-secgw/test/run_test.sh  |  18 ++-
 .../test/trs_3descbc_sha1_common_defs.sh   |  73 +++
 examples/ipsec-secgw/test/trs_3descbc_sha1_defs.sh |  67 ++
 .../test/trs_3descbc_sha1_esn_atom_defs.sh |   5 +
 .../ipsec-secgw/test/trs_3descbc_sha1_esn_defs.sh  |  66 ++
 .../ipsec-secgw/test/trs_3descbc_sha1_old_defs.sh  |   5 +
 .../test/trs_aesctr_sha1_common_defs.sh|  69 ++
 examples/ipsec-secgw/test/trs_aesctr_sha1_defs.sh  |  67 ++
 .../test/trs_aesctr_sha1_esn_atom_defs.sh  |   5 +
 .../ipsec-secgw/test/trs_aesctr_sha1_esn_defs.sh   |  66 ++
 .../ipsec-secgw/test/trs_aesctr_sha1_old_defs.sh   |   5 +
 .../test/tun_3descbc_sha1_common_defs.sh   |  72 +++
 examples/ipsec-secgw/test/tun_3descbc_sha1_defs.sh |  70 ++
 .../test/tun_3descbc_sha1_esn_atom_defs.sh |   5 +
 .../ipsec-secgw/test/tun_3descbc_sha1_esn_defs.sh  |  70 ++
 .../ipsec-secgw/test/tun_3descbc_sha1_old_defs.sh  |   5 +
 .../test/tun_aesctr_sha1_common_defs.sh|  68 ++
 examples/ipsec-secgw/test/tun_aesctr_sha1_defs.sh  |  70 ++
 .../test/tun_aesctr_sha1_esn_atom_defs.sh  |   5 +
 .../ipsec-secgw/test/tun_aesctr_sha1_esn_defs.sh   |  70 ++
 .../ipsec-secgw/test/tun_aesctr_sha1_old_defs.sh   |   5 +
 lib/librte_ipsec/crypto.h  |  17 +++
 lib/librte_ipsec/sa.c  | 143 ++---
 lib/librte_ipsec/sa.h  |  24 
 25 files changed, 1050 insertions(+), 24 deletions(-)
 create mode 100644 examples/ipsec-secgw/test/trs_3descbc_sha1_common_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_3descbc_sha1_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_3descbc_sha1_esn_atom_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_3descbc_sha1_esn_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_3descbc_sha1_old_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesctr_sha1_common_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesctr_sha1_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesctr_sha1_esn_atom_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesctr_sha1_esn_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesctr_sha1_old_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_3descbc_sha1_common_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_3descbc_sha1_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_3descbc_sha1_esn_atom_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_3descbc_sha1_esn_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_3descbc_sha1_old_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesctr_sha1_common_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesctr_sha1_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesctr_sha1_esn_atom_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesctr_sha1_esn_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesctr_sha1_old_defs.sh

-- 
2.14.5

[dpdk-dev] [PATCH 4/4] ipsec-secgw: add 3des test files

[Fan Zhang]

This patch adds the functional test scripts to ipsec-secgw
sample application for both transport and tunnel working
mode.

Signed-off-by: Fan Zhang 
---
 examples/ipsec-secgw/test/run_test.sh  | 10 ++-
 .../test/trs_3descbc_sha1_common_defs.sh   | 73 ++
 examples/ipsec-secgw/test/trs_3descbc_sha1_defs.sh | 67 
 .../test/trs_3descbc_sha1_esn_atom_defs.sh |  5 ++
 .../ipsec-secgw/test/trs_3descbc_sha1_esn_defs.sh  | 66 +++
 .../ipsec-secgw/test/trs_3descbc_sha1_old_defs.sh  |  5 ++
 .../test/tun_3descbc_sha1_common_defs.sh   | 72 +
 examples/ipsec-secgw/test/tun_3descbc_sha1_defs.sh | 70 +
 .../test/tun_3descbc_sha1_esn_atom_defs.sh |  5 ++
 .../ipsec-secgw/test/tun_3descbc_sha1_esn_defs.sh  | 70 +
 .../ipsec-secgw/test/tun_3descbc_sha1_old_defs.sh  |  5 ++
 11 files changed, 447 insertions(+), 1 deletion(-)
 create mode 100644 examples/ipsec-secgw/test/trs_3descbc_sha1_common_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_3descbc_sha1_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_3descbc_sha1_esn_atom_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_3descbc_sha1_esn_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_3descbc_sha1_old_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_3descbc_sha1_common_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_3descbc_sha1_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_3descbc_sha1_esn_atom_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_3descbc_sha1_esn_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_3descbc_sha1_old_defs.sh

diff --git a/examples/ipsec-secgw/test/run_test.sh 
b/examples/ipsec-secgw/test/run_test.sh
index 435de5da6..492156aae 100644
--- a/examples/ipsec-secgw/test/run_test.sh
+++ b/examples/ipsec-secgw/test/run_test.sh
@@ -40,7 +40,15 @@ tun_aesctr_sha1_old \
 trs_aesctr_sha1 \
 trs_aesctr_sha1_esn \
 trs_aesctr_sha1_esn_atom \
-trs_aesctr_sha1_old"
+trs_aesctr_sha1_old \
+tun_3descbc_sha1 \
+tun_3descbc_sha1_esn \
+tun_3descbc_sha1_esn_atom \
+tun_3descbc_sha1_old \
+trs_3descbc_sha1 \
+trs_3descbc_sha1_esn \
+trs_3descbc_sha1_esn_atom \
+trs_3descbc_sha1_old"
 
 DIR=`dirname $0`
 
diff --git a/examples/ipsec-secgw/test/trs_3descbc_sha1_common_defs.sh 
b/examples/ipsec-secgw/test/trs_3descbc_sha1_common_defs.sh
new file mode 100644
index 0..bb4cef6a9
--- /dev/null
+++ b/examples/ipsec-secgw/test/trs_3descbc_sha1_common_defs.sh
@@ -0,0 +1,73 @@
+#! /bin/bash
+
+CRYPTO_DEV=${CRYPTO_DEV:-'--vdev="crypto_aesni_mb0"'}
+
+#generate cfg file for ipsec-secgw
+config_secgw()
+{
+   cat < ${SGW_CFG_FILE}
+#SP in IPv4 rules
+sp ipv4 in esp protect 7 pri 2 src ${REMOTE_IPV4}/32 dst ${LOCAL_IPV4}/32 \
+sport 0:65535 dport 0:65535
+sp ipv4 in esp bypass pri 1 sport 0:65535 dport 0:65535
+
+#SP out IPv4 rules
+sp ipv4 out esp protect 7 pri 2 src ${LOCAL_IPV4}/32 dst ${REMOTE_IPV4}/32 \
+sport 0:65535 dport 0:65535
+sp ipv4 out esp bypass pri 1 sport 0:65535 dport 0:65535
+
+#sp in IPv6 rules
+sp ipv6 in esp protect 9 pri 2 src ${REMOTE_IPV6}/128 dst ${LOCAL_IPV6}/128 \
+sport 0:65535 dport 0:65535
+sp ipv6 in esp bypass pri 1 sport 0:65535 dport 0:65535
+
+#SP out IPv6 rules
+sp ipv6 out esp protect 9 pri 2 src ${LOCAL_IPV6}/128 dst ${REMOTE_IPV6}/128 \
+sport 0:65535 dport 0:65535
+sp ipv6 out esp bypass pri 1 sport 0:65535 dport 0:65535
+
+#SA in rules
+sa in 7 cipher_algo 3des-cbc \
+cipher_key \
+de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+auth_algo sha1-hmac \
+auth_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+mode transport
+
+sa in 9 cipher_algo 3des-cbc \
+cipher_key \
+de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+auth_algo sha1-hmac \
+auth_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+mode transport
+
+#SA out rules
+sa out 7 cipher_algo 3des-cbc \
+cipher_key \
+de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+auth_algo sha1-hmac \
+auth_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+mode transport
+
+#SA out rules
+sa out 9 cipher_algo 3des-cbc \
+cipher_key \
+de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+auth_algo sha1-hmac \
+auth_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+mode transport
+
+#Routing rules
+rt ipv4 dst ${REMOTE_IPV4}/32 port 0
+rt ipv4 dst ${LOCAL_IPV4}/32 port 1
+
+rt ipv6 dst ${REMOTE_IPV6}/128 port 0
+rt ipv6 dst ${LOCAL_IPV6}/128 port 1
+
+#neighbours
+neigh port 0 ${REMOTE_MAC}
+neigh port 1 ${LOCAL_MAC}
+EOF
+
+   cat ${SGW_CFG_FILE}
+}
diff --git a/examples/ipsec-secgw/test/trs_3descbc_sha1_defs.sh 
b/examples/ipsec-secgw/test/trs_3descbc_sha1_defs.sh
new file mode 100644
index 0..31f94492f
--- /dev/null
+++ b/examples/ipsec-secgw/test/trs_3descbc_sha1_defs.sh
@

Re: [dpdk-dev] [PATCH] net/ena: get device info statically

[Ferruh Yigit]

On 2/15/2019 8:36 AM, Michal Krawczyk wrote:
> Whenever the app is calling rte_eth_dev_info_get(), it shouldn't use the
> admin command. It was causing problems, if it was called from the
> secondary process - the main process was crashing, and the secondary app
> wasn't getting any result, as the admin request couldn't be processed by
> the process which was requesting the data.
> 
> To fix that, the data is being written to the adapter structure during
> device initialization routine.
> 
> Signed-off-by: Michal Krawczyk 

Applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [PATCH] doc: fix a minor typo in testpmd guide

[Ferruh Yigit]

On 2/18/2019 1:26 AM, Zhao1, Wei wrote:

> 
> 
>> -Original Message-
>> From: Rami Rosen [mailto:ramir...@gmail.com]
>> Sent: Saturday, February 16, 2019 7:13 PM
>> To: dev@dpdk.org
>> Cc: Zhao1, Wei ; sta...@dpdk.org; Rami Rosen
>> 
>> Subject: [PATCH] doc: fix a minor typo in testpmd guide
>>
>> This patch fixes a minor typo in testpmd guide.
>>
>> Cc: sta...@dpdk.org
>> Fixes: 3c272b280a50 ("app/testpmd: add commands for RSS queue region")
>>
>> Signed-off-by: Rami Rosen 
>
> Acked-by: Wei Zhao 
Applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [RFC 00/14] prefix network structures

[Olivier Matz]

On Mon, Feb 18, 2019 at 12:37:41PM +, Ferruh Yigit wrote:
> On 2/13/2019 11:48 AM, Yigit, Ferruh wrote:
> > On 12/27/2018 9:35 AM, Olivier Matz wrote:
> >> Hi,
> >>
> >> On Fri, Dec 21, 2018 at 03:14:29PM +, Ferruh Yigit wrote:
> >>> On 12/21/2018 2:38 PM, Wiles, Keith wrote:
> 
> 
> > On Dec 20, 2018, at 5:48 PM, Stephen Hemminger 
> >  wrote:
> >
> > On Thu, 20 Dec 2018 21:59:37 +
> > Ferruh Yigit  wrote:
> >
> >> On 10/24/2018 9:18 AM, olivier.matz at 6wind.com (Olivier Matz) wrote:
> >>> This RFC targets 19.02.
> >>>
> >>> The rte_net headers conflict with the libc headers, because
> >>> some definitions are duplicated, sometimes with few differences.
> >>> This was discussed in [1], and more recently at the techboard.
> >>>
> >>> Before sending the deprecation notice (target for this is 18.11),
> >>> here is a draft that can be discussed.
> >>>
> >>> This RFC adds the rte_ (or RTE_) prefix to all structures, functions
> >>> and defines in rte_net library. This is a big changeset, that will
> >>> break the API of many functions, but not the ABI.
> >>>
> >>> One question I'm asking is how can we manage the transition.
> >>> Initially, I hoped it was possible to have a compat layer during
> >>> one release (supporting both prefixed and unprefixed names), but
> >>> now that the patch is done, it seems the impact is too big, and
> >>> impacts too many libraries.
> >>>
> >>> Few examples:
> >>>  - rte_eth_macaddr_get/add/remove() use a (struct rte_ether_addr *)
> >>>  - many rte_flow structures use the rte_ prefixed net structures
> >>>  - the mac field of virtio_net structure is rte_ether_addr
> >>>  - the first arg of rte_thash_load_v6_addrs is (struct rte_ipv6_hdr *)
> >>>  ...
> >>>
> >>> Therefore, it is clear that doing this would break the compilation
> >>> of many external applications.
> >>>
> >>> Another drawback we need to take in account: it will make the
> >>> backport of patches more difficult, although this is something
> >>> that could be tempered by a script.
> >>>
> >>> While it is obviously better to have a good namespace convention, 
> >>> we need to identify the issues we have today before deciding it's
> >>> worth doing the change.
> >>>
> >>> Comments?  
> >>
> >> Is there an consensus about the patchset? There was a decision on 
> >> techboard to
> >> go with this change (adding rte_ prefix) [1].
> >>
> >>
> >> This is something that will affect DPDK consumers. Since many APIs are 
> >> changing
> >> most probably will break API compatibility for many libraries.
> >>
> >> Meanwhile the conflict with the libc headers mentioned a few times in 
> >> the past,
> >> this is something we need to fix.
> >>
> >> There are a few comments reluctant to this big modification, but what I
> >> understand from Olivier's response both using BSD defines or having
> >> compatibility headers in DPDK won't solve the problem completely.
> >>
> >> And assuming we will continue with this solution, another question is 
> >> do we
> >> still want to push in 19.02 scope? (And from process point of view I 
> >> think a
> >> deprecation notice is not merged for this change in 18.11 scope.)
> >>
> >> With the prediction of 19.05 will be big and already break API/ABI for 
> >> some
> >> libraries, can we push this into 19.05 as an early merge into repo?
> >>
> >> And I think this patch will affect LTS releases and will break auto 
> >> backporting
> >> for many fixes because it touches many places, so pushing this change 
> >> even to
> >> next LTS (19.11) can be an option.
> >>
> >>
> >> Olivier, Thomas,
> >>
> >> What do you think about postponing this to 19.05 or even 19.11 ?
> >>
> >>
> >>
> >> [1]
> >> https://mails.dpdk.org/archives/dev/2018-October/116695.html
> >>
> >>>
> >>>
> >>> Things that are missing in RFC:
> >>> - test with FreeBSD
> >>> - manually fix some indentation issues
> >>>
> >>>
> >>> Olivier Matz (14):
> >>>  net: add rte prefix to arp structures
> >>>  net: add rte prefix to arp defines
> >>>  net: add rte prefix to ether structures
> >>>  net: add rte prefix to ether functions
> >>>  net: add rte prefix to ether defines
> >>>  net: add rte prefix to esp structure
> >>>  net: add rte prefix to gre structure
> >>>  net: add rte prefix to icmp structure
> >>>  net: add rte prefix to icmp defines
> >>>  net: add rte prefix to ip structure
> >>>  net: add rte prefix to ip defines
> >>>  net: add rte prefix to sctp structure
> >>>  net: add rte prefix to tcp structure
> >>>  net: add rte prefix to udp structure  
> >>
> >>
> 

Re: [dpdk-dev] [PATCH] ethdev: remove unused variable

[Ferruh Yigit]

On 2/14/2019 5:34 PM, Andrew Rybchenko wrote:
> On 2/14/19 7:29 PM, Thomas Monjalon wrote:
>> When removing the old attach function, the racy variable for getting
>> the last port id became unused.
>>
>> Fixes: c9cce42876f5 ("ethdev: remove deprecated attach/detach functions")
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Thomas Monjalon 
> Reviewed-by: Andrew Rybchenko 

Applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [PATCH v2 3/3] net/af_packet: get 'framesz' from the iface's MTU

[Yigit, Ferruh]

On 11/28/2018 1:12 PM, Lam, Tiago wrote:
> On 27/11/2018 17:43, Ferruh Yigit wrote:
>> On 11/20/2018 10:26 AM, Tiago Lam wrote:
>>> Use the underlying MTU to calculate the framsize to be used for the mmap
>>> RINGs. This is to make it more flexible on deployments with different
>>> MTU requirements, instead of using a pre-defined value of 2048B.
>>
>> This behavior change should be documented in af_packet documentation which is
>> missing unfortunately.
>> Would you able to introduce the initial/basic af_packet doc to at least to
>> document device argument? If not please let me know, I can work on it.
>>
> 
> Thanks for the review, Ferruh.
> 
> Yeah, I don't mind cooking something up and submitting here for review;
> I'll wait a couple of days for a reply from John W. before proceeding,
> though.
> 
> But given there's no documentation for af_packet yet, do you prefer to
> wait for that to be available, and apply it all together? Or could that
> be applied later as part of another patch?

Unfortunately Tiago was not able to work on this task anymore.
And since Tiago's af_packet doc update already merged, I was planning to
complete the task and applied the comments into his patchset but had a few
questions, sharing here in case there are more interested people on task, cc'ed
Ian & Kevin.

Code is not functioning correct when there are gaps in the block, I mean when
block size is not multiple of frame size. There can be some assumption in the
code that memory is continuous.

Also I am not sure the benefit of the using MTU for this case. There are a few
restrictions, block size should be multiple of page size, it is 4K by default.
When using MTU, 1500, for frame size, instead of 2048 Bytes hardcoded value,
still only 2 frames fit into blocksize and there is no benefit, (and it is not
functioning with current code as I mentioned above.)
So this can be required for the cases MTU is bigger than 2048, not sure if this
is the concern of the patch.
Also it can provide some memory optimization when MTU is 1024 bytes or less, so
this provides memory optimization more than flexibility on deployment.

Hi Ian, Kevin,

Are you aware of any use case of this patch in OvS?

Thanks,
ferruh

Re: [dpdk-dev] [PATCH 1/1] net/qede: fix tx_pkt_prepare for tunnel packets

[Ferruh Yigit]

On 2/13/2019 5:53 PM, Shahed Shaikh wrote:
> This patch fixes a regression introduced by
> commit 49d3978d5723("net/qede: fix Tx tunnel offload support mask")
> in which qede_xmit_prep_pkts() breaks the loop for successful
> check of Tunneling offload flags instead of continuing, resulting
> in tx_pkt_prepare return a failure.
> 
> Fixes: 49d3978d5723 ("net/qede: fix Tx tunnel offload support mask")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Shahed Shaikh 

Applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [PATCH] doc: deprecate KNI ethtool support

[Rami Rosen]

Acked-by: Rami Rosen 

בתאריך יום ב׳, 18 בפבר׳ 2019, 14:30, מאת Ferruh Yigit <
ferruh.yi...@intel.com>:

> Remove KNI ethtool support.
>
> Signed-off-by: Ferruh Yigit 
> ---
> RFC Patch: https://patches.dpdk.org/patch/49025/
> ---
>  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 1b4fcb7e6..0491eeea1 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -75,3 +75,11 @@ Deprecation Notices
>
>  * crypto/aesni_mb: the minimum supported intel-ipsec-mb library version
> will be
>changed from 0.49.0 to 0.52.0.
> +
> +* kni: remove KNI ethtool support. To clarify, this is not to remove the
> KNI,
> +  but only to remove ethtool support of it that is disabled by default and
> +  can be enabled via ``CONFIG_RTE_KNI_KMOD_ETHTOOL`` config option.
> +  Existing KNI ethtool implementation is only supported by ``igb`` &
> ``ixgbe``
> +  drivers, by using a copy of kernel drivers in DPDK. This model can't be
> extend
> +  to all drivers in DPDK and it is too much effort to maintain kernel
> modules in DPDK.
> +  As a result users won't be able to use ``ethtool`` via ``igb`` &
> ``ixgbe`` anymore.
> --
> 2.20.1
>
>

Re: [dpdk-dev] [PATCH 1/5] app/testpmd: remove unused fwd_ctx field

[Rami Rosen]

I believe this patch should be cc'ed/sent to sta...@dpdk.org

Reviewed-by: Rami Rosen 

On Thu, Feb 14, 2019 at 5:43 PM David Marchand 
wrote:

> Remove some leftover from a previous rework.
>
> Fixes: c4bcc342c8ee ("app/testpmd: refactor ieee1588 forwarding")
> Signed-off-by: David Marchand 
> ---
>  app/test-pmd/testpmd.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
> index fa48878..85b791b 100644
> --- a/app/test-pmd/testpmd.h
> +++ b/app/test-pmd/testpmd.h
> @@ -173,7 +173,6 @@ struct rte_port {
> uint16_ttunnel_tso_segsz; /**< Segmentation
> offload MSS for tunneled pkts. */
> uint16_ttx_vlan_id;/**< The tag ID */
> uint16_ttx_vlan_id_outer;/**< The outer tag ID */
> -   void*fwd_ctx;   /**< Forwarding mode context */
> uint64_trx_bad_ip_csum; /**< rx pkts with bad ip
> checksum  */
> uint64_trx_bad_l4_csum; /**< rx pkts with bad l4
> checksum */
> uint64_trx_bad_outer_l4_csum;
> --
> 1.8.3.1
>
>

-- 
regards,
Rami Rosen

Re: [dpdk-dev] [PATCH v3] service: fix parameter type

[Rami Rosen]

Reviewed-by: Rami Rosen 

On Fri, Feb 15, 2019 at 12:29 PM Nikhil Rao  wrote:

> The type of value parameter to rte_service_attr_get
> should be uint64_t *, since the attributes
> are of type uint64_t.
>
> Fixes: 4d55194d76a4 ("service: add attribute get function")
>
> Reviewed-by: Gage Eads 
> Signed-off-by: Nikhil Rao 
> Acked-by: Harry van Haaren 
> ---
>  lib/librte_eal/common/include/rte_service.h | 2 +-
>  lib/librte_eal/common/rte_service.c | 2 +-
>  test/test/test_service_cores.c  | 2 +-
>  doc/guides/rel_notes/deprecation.rst| 4 
>  doc/guides/rel_notes/release_19_05.rst  | 5 -
>  lib/librte_eal/bsdapp/eal/Makefile  | 2 +-
>  lib/librte_eal/linuxapp/eal/Makefile| 2 +-
>  lib/librte_eal/meson.build  | 2 +-
>  8 files changed, 10 insertions(+), 11 deletions(-)
>
> v2:
> * Update release notes.
> * Update library version in makefiles.
>
> v3:
> * Remove deprecation notice.
>
> diff --git a/lib/librte_eal/common/include/rte_service.h
> b/lib/librte_eal/common/include/rte_service.h
> index 34b41af..670c89a 100644
> --- a/lib/librte_eal/common/include/rte_service.h
> +++ b/lib/librte_eal/common/include/rte_service.h
> @@ -372,7 +372,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
>   * -EINVAL Invalid id, attr_id or attr_value was NULL.
>   */
>  int32_t rte_service_attr_get(uint32_t id, uint32_t attr_id,
> -   uint32_t *attr_value);
> +   uint64_t *attr_value);
>
>  /**
>   * Reset all attribute values of a service.
> diff --git a/lib/librte_eal/common/rte_service.c
> b/lib/librte_eal/common/rte_service.c
> index 03fde97..5f75e5a 100644
> --- a/lib/librte_eal/common/rte_service.c
> +++ b/lib/librte_eal/common/rte_service.c
> @@ -734,7 +734,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
>  }
>
>  int32_t
> -rte_service_attr_get(uint32_t id, uint32_t attr_id, uint32_t *attr_value)
> +rte_service_attr_get(uint32_t id, uint32_t attr_id, uint64_t *attr_value)
>  {
> struct rte_service_spec_impl *s;
> SERVICE_VALID_GET_OR_ERR_RET(id, s, -EINVAL);
> diff --git a/test/test/test_service_cores.c
> b/test/test/test_service_cores.c
> index ec31882..82bb2ce 100644
> --- a/test/test/test_service_cores.c
> +++ b/test/test/test_service_cores.c
> @@ -259,7 +259,7 @@ static int32_t dummy_mt_safe_cb(void *args)
> rte_service_set_stats_enable(id, 1);
>
> uint32_t attr_id = UINT32_MAX;
> -   uint32_t attr_value = 0xdead;
> +   uint64_t attr_value = 0xdead;
> /* check error return values */
> TEST_ASSERT_EQUAL(-EINVAL, rte_service_attr_get(id, attr_id,
> &attr_value),
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 1b4fcb7..93ed31f 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -20,10 +20,6 @@ Deprecation Notices
>  * kvargs: The function ``rte_kvargs_process`` will get a new parameter
>for returning key match count. It will ease handling of no-match case.
>
> -* eal: The ``attr_value`` parameter of ``rte_service_attr_get()``
> -  will be changed from ``uint32_t *`` to ``uint64_t *``
> -  as the attributes are of type ``uint64_t``.
> -
>  * eal: both declaring and identifying devices will be streamlined in
> v18.11.
>New functions will appear to query a specific port from buses, classes
> of
>device and device drivers. Device declaration will be made coherent
> with the
> diff --git a/doc/guides/rel_notes/release_19_05.rst
> b/doc/guides/rel_notes/release_19_05.rst
> index 2b0f60d..b8ed3d3 100644
> --- a/doc/guides/rel_notes/release_19_05.rst
> +++ b/doc/guides/rel_notes/release_19_05.rst
> @@ -94,6 +94,9 @@ API Changes
> Also, make sure to start the actual text at the margin.
> =
>
> +eal: as shown in the 19.02 deprecation notice, the type of the
> ``attr_value``
> +  parameter of the function ``rte_service_attr_get()`` has been changed
> +  from ``uint32_t *`` to ``uint64_t *``.
>
>  ABI Changes
>  ---
> @@ -143,7 +146,7 @@ The libraries prepended with a plus sign were
> incremented in this version.
>   librte_compressdev.so.1
>   librte_cryptodev.so.6
>   librte_distributor.so.1
> - librte_eal.so.9
> ++librte_eal.so.10
>   librte_efd.so.1
>   librte_ethdev.so.11
>   librte_eventdev.so.6
> diff --git a/lib/librte_eal/bsdapp/eal/Makefile
> b/lib/librte_eal/bsdapp/eal/Makefile
> index bfeddaa..4bc8555 100644
> --- a/lib/librte_eal/bsdapp/eal/Makefile
> +++ b/lib/librte_eal/bsdapp/eal/Makefile
> @@ -22,7 +22,7 @@ LDLIBS += -lrte_kvargs
>
>  EXPORT_MAP := ../../rte_eal_version.map
>
> -LIBABIVER := 9
> +LIBABIVER := 10
>
>  # specific to bsdapp exec-env
>  SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
> diff --git a/lib/librte_eal/linuxapp/eal/Makefile
> b/lib/librte_eal/

Re: [dpdk-dev] [PATCH 2/5] app/testpmd: add missing newline when showing statistics

[Rami Rosen]

+1
Reviewed-by: Rami Rosen 

On Thu, Feb 14, 2019 at 5:43 PM David Marchand 
wrote:

> Having the standard stats and the rx burst stats on the same line gives a
> really long line and is not consistent with the rest.
>
> Before:
>   RX-packets: 3542977TX-packets: 3542971TX-dropped: 6
>  RX-bursts : 499440 [24% of 2 pkts + 15% of 1 pkts + 61% of others]
>   TX-bursts : 499440 [24% of 2 pkts + 15% of 1 pkts + 61% of others]
>
> After:
>   RX-packets: 4629969TX-packets: 4629969TX-dropped: 0
>   RX-bursts : 663328 [19% of 2 pkts + 17% of 3 pkts + 64% of others]
>   TX-bursts : 663328 [19% of 2 pkts + 17% of 3 pkts + 64% of others]
>
> Signed-off-by: David Marchand 
> ---
>  app/test-pmd/testpmd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 98c1baa..984155a 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -1459,7 +1459,7 @@ struct extmem_param {
>"TX Port=%2d/Queue=%2d %s\n",
>fwd_top_stats_border, fs->rx_port, fs->rx_queue,
>fs->tx_port, fs->tx_queue, fwd_top_stats_border);
> -   printf("  RX-packets: %-14u TX-packets: %-14u TX-dropped: %-14u",
> +   printf("  RX-packets: %-14u TX-packets: %-14u TX-dropped: %-14u\n",
>fs->rx_packets, fs->tx_packets, fs->fwd_dropped);
>
> /* if checksum mode */
> --
> 1.8.3.1
>
>

-- 
regards,
Rami Rosen

[dpdk-dev] [PATCH] mbuf: move headers not fragmented check to checksum

[Andrew Rybchenko]

rte_validate_tx_offload() is used in Tx prepare callbacks
(RTE_LIBRTE_ETHDEV_DEBUG only) to check Tx offloads consistency.
Requirement that packet headers should not be fragmented is not
documented and unclear where it comes from except
rte_net_intel_cksum_prepare() functions which relies on it.

It could be NIC vendor specific driver or hardware limitation, but,
if so, it should be documented and checked in corresponding Tx
prepare callbacks.

Signed-off-by: Andrew Rybchenko 
Acked-by: Konstantin Ananyev 
---
Looks good to me, though extra-testing would be needed.
Konstantin Ananyev 

 lib/librte_mbuf/rte_mbuf.h | 12 
 lib/librte_net/rte_net.h   | 17 +
 2 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index d961cca..73daa81 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -2257,23 +2257,11 @@ static inline int rte_pktmbuf_chain(struct rte_mbuf 
*head, struct rte_mbuf *tail
 rte_validate_tx_offload(const struct rte_mbuf *m)
 {
uint64_t ol_flags = m->ol_flags;
-   uint64_t inner_l3_offset = m->l2_len;
 
/* Does packet set any of available offloads? */
if (!(ol_flags & PKT_TX_OFFLOAD_MASK))
return 0;
 
-   if (ol_flags & PKT_TX_OUTER_IP_CKSUM)
-   /* NB: elaborating the addition like this instead of using
-* += gives the result uint64_t type instead of int,
-* avoiding compiler warnings on gcc 8.1 at least */
-   inner_l3_offset = inner_l3_offset + m->outer_l2_len +
- m->outer_l3_len;
-
-   /* Headers are fragmented */
-   if (rte_pktmbuf_data_len(m) < inner_l3_offset + m->l3_len + m->l4_len)
-   return -ENOTSUP;
-
/* IP checksum can be counted only for IPv4 packet */
if ((ol_flags & PKT_TX_IP_CKSUM) && (ol_flags & PKT_TX_IPV6))
return -EINVAL;
diff --git a/lib/librte_net/rte_net.h b/lib/librte_net/rte_net.h
index e59760a..bd75aea 100644
--- a/lib/librte_net/rte_net.h
+++ b/lib/librte_net/rte_net.h
@@ -118,10 +118,27 @@ uint32_t rte_net_get_ptype(const struct rte_mbuf *m,
struct udp_hdr *udp_hdr;
uint64_t inner_l3_offset = m->l2_len;
 
+   /*
+* Does packet set any of available offloads?
+* Mainly it is required to avoid fragmented headers check if
+* no offloads are requested.
+*/
+   if (!(ol_flags & PKT_TX_OFFLOAD_MASK))
+   return 0;
+
if ((ol_flags & PKT_TX_OUTER_IP_CKSUM) ||
(ol_flags & PKT_TX_OUTER_IPV6))
inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
 
+   /*
+* Check if headers are fragmented.
+* The check could be less strict depending on which offloads are
+* requested and headers to be used, but let's keep it simple.
+*/
+   if (unlikely(rte_pktmbuf_data_len(m) <
+inner_l3_offset + m->l3_len + m->l4_len))
+   return -ENOTSUP;
+
if (ol_flags & PKT_TX_IPV4) {
ipv4_hdr = rte_pktmbuf_mtod_offset(m, struct ipv4_hdr *,
inner_l3_offset);
-- 
1.8.3.1

[dpdk-dev] [PATCH] app/testpmd: fix tx vlan and qinq insert enable

[Nithin Kumar Dabilpuram]

Tx VLAN & QinQ insert enable need not depend on
Rx VLAN offload ETH_VLAN_EXTEND_OFFLOAD. Also enable
DEV_TX_OFFLOAD_VLAN_INSERT for tx_qinq_set() as it takes
both vlan id's.

Signed-off-by: Nithin Dabilpuram 
---
 app/test-pmd/config.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index b9e5dd9..0243f07 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2955,7 +2955,6 @@ vlan_tpid_set(portid_t port_id, enum rte_vlan_type 
vlan_type, uint16_t tp_id)
 void
 tx_vlan_set(portid_t port_id, uint16_t vlan_id)
 {
-   int vlan_offload;
struct rte_eth_dev_info dev_info;
 
if (port_id_is_invalid(port_id, ENABLED_WARN))
@@ -2963,11 +2962,6 @@ tx_vlan_set(portid_t port_id, uint16_t vlan_id)
if (vlan_id_is_invalid(vlan_id))
return;
 
-   vlan_offload = rte_eth_dev_get_vlan_offload(port_id);
-   if (vlan_offload & ETH_VLAN_EXTEND_OFFLOAD) {
-   printf("Error, as QinQ has been enabled.\n");
-   return;
-   }
rte_eth_dev_info_get(port_id, &dev_info);
if ((dev_info.tx_offload_capa & DEV_TX_OFFLOAD_VLAN_INSERT) == 0) {
printf("Error: vlan insert is not supported by port %d\n",
@@ -2983,7 +2977,6 @@ tx_vlan_set(portid_t port_id, uint16_t vlan_id)
 void
 tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t vlan_id_outer)
 {
-   int vlan_offload;
struct rte_eth_dev_info dev_info;
 
if (port_id_is_invalid(port_id, ENABLED_WARN))
@@ -2993,11 +2986,6 @@ tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t 
vlan_id_outer)
if (vlan_id_is_invalid(vlan_id_outer))
return;
 
-   vlan_offload = rte_eth_dev_get_vlan_offload(port_id);
-   if (!(vlan_offload & ETH_VLAN_EXTEND_OFFLOAD)) {
-   printf("Error, as QinQ hasn't been enabled.\n");
-   return;
-   }
rte_eth_dev_info_get(port_id, &dev_info);
if ((dev_info.tx_offload_capa & DEV_TX_OFFLOAD_QINQ_INSERT) == 0) {
printf("Error: qinq insert not supported by port %d\n",
@@ -3006,7 +2994,8 @@ tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t 
vlan_id_outer)
}
 
tx_vlan_reset(port_id);
-   ports[port_id].dev_conf.txmode.offloads |= DEV_TX_OFFLOAD_QINQ_INSERT;
+   ports[port_id].dev_conf.txmode.offloads |= (DEV_TX_OFFLOAD_VLAN_INSERT |
+   DEV_TX_OFFLOAD_QINQ_INSERT);
ports[port_id].tx_vlan_id = vlan_id;
ports[port_id].tx_vlan_id_outer = vlan_id_outer;
 }
-- 
2.8.4