Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
13/10/2021 07:36, Anoob Joseph: > From: Thomas Monjalon > > 12/10/2021 16:47, Kinsella, Ray: > > > On 12/10/2021 15:18, Anoob Joseph wrote: > > > > From: Thomas Monjalon > > > >> 12/10/2021 15:38, Anoob Joseph: > > > >>> From: Thomas Monjalon > > > 12/10/2021 13:34, Anoob Joseph: > > > > From: Kinsella, Ray > > > >> On 12/10/2021 11:50, Anoob Joseph wrote: > > > >>> From: Akhil Goyal > > > > On 08/10/2021 21:45, Akhil Goyal wrote: > > > >> Remove *_LIST_END enumerators from asymmetric crypto > > lib to > > > >> avoid ABI breakage for every new addition in enums. > > > >> > > > >> Signed-off-by: Akhil Goyal > > > >> --- > > > >> - } else if (xform->xform_type >= > > > > RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END > > > >> + } else if (xform->xform_type > > > > RTE_CRYPTO_ASYM_XFORM_ECPM > > > [...] > > > > > > > > So I am not sure that this is an improvement. > > > > > > Indeed, it is not an improvement. > > > > > > > The cryptodev issue we had, was that _LIST_END was being > > > > used to size arrays. > > > > And that broke when new algorithms got added. Is that an > > > > issue, in this > > > >> case? > > > > > > Yes we did this same exercise for symmetric crypto enums > > earlier. > > > Asym enums were left as it was experimental at that point. > > > They are still experimental, but thought of making this > > > uniform throughout DPDK enums. > > > > > > > > > > > I am not sure that swapping out _LIST_END, and then > > > > littering the code with RTE_CRYPTO_ASYM_XFORM_ECPM and > > > > RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an > > > improvement > > > here. > > > > > > > > My 2c is that from an ABI PoV > > RTE_CRYPTO_ASYM_OP_LIST_END is > > > > not better or worse, than > > > >> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE? > > > > > > > > Interested to hear other thoughts. > > > > > > I don’t have any better solution for avoiding ABI issues for now. > > > The change is for avoiding ABI breakage. But we can drop this > > > patch For now as asym is still experimental. > > > >>> > > > >>> [Anoob] Having LIST_END would preclude new additions to > > > >>> asymmetric > > > algos? > > > >> If yes, then I would suggest we address it now. > > > >> > > > >> Not at all - but it can be problematic, if two versions of DPDK > > > >> disagree with the value of LIST_END. > > > >> > > > >>> Looking at the "problematic changes", we only have 2-3 > > > >>> application & PMD changes. For unit test application, we could > > > >>> may be do something like, > > > >> > > > >> The essental functionality not that different, I am just not > > > >> sure that the verbosity below is helping. > > > >> What you are really trying to guard against is people using > > > >> LIST_END to size arrays. > > > > > > > > [Anoob] Our problem is application using LIST_END (which comes > > > > from library) > > > to determine the number of iterations for the loop. My suggestion > > > is to modify the UT such that, we could use RTE_DIM(types) (which > > > comes from application) to determine iterations of loop. This > > > would solve the > > > >> problem, right? > > > > > > The problem is not the application. > > > Are you asking the app to define DPDK types? > > > >>> > > > >>> [Anoob] I didn't understand how you concluded that. > > > >> > > > >> Because you define a specific array in the test app. > > > >> > > > >>> The app is supposed to test "n" asymmetric features supported by > > DPDK. > > > >> Currently, it does that by looping from 0 to LIST_END which happens > > > >> to give you the first n features. Now, if we add any new asymmetric > > > >> feature, LIST_END value would change. Isn't that the very reason > > > >> why we removed LIST_END from symmetric library and applications? > > > >> > > > >> Yes > > > >> > > > >>> Now coming to what I proposed, the app is supposed to test "n" > > > >>> asymmetric > > > >> features. LIST_END helps in doing the loops. If we remove LIST_END, > > > >> then application will not be in a position to do a loop. My > > > >> suggestion is, we list the types that are supposed to be tested by > > > >> the app, and let that array be used as feature list. > > > >>> > > > >>> PS: Just to reiterate, my proposal is just a local array which > > > >>> would hold DPDK > > > >> defined RTE enum values for the features that would be tested by > > > >> this app/function. > > > >> > > > >> I am more concerned by the general case than the test app. > > > >> I think a function returning a number is more app-friendly. > > > > > > > > [Anoob] Indeed. But there are 3 LIS
Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
Hi Akhil, Ray, Thomas, Please see inline. Thanks, Anoob > -Original Message- > From: Thomas Monjalon > Sent: Wednesday, October 13, 2021 12:32 PM > To: Akhil Goyal ; dev@dpdk.org; Kinsella, Ray > ; Anoob Joseph > Cc: david.march...@redhat.com; hemant.agra...@nxp.com; > pablo.de.lara.gua...@intel.com; fiona.tr...@intel.com; > declan.dohe...@intel.com; ma...@nvidia.com; g.si...@nxp.com; > roy.fan.zh...@intel.com; jianjay.z...@huawei.com; asoma...@amd.com; > ruifeng.w...@arm.com; konstantin.anan...@intel.com; > radu.nico...@intel.com; ajit.khapa...@broadcom.com; Nagadheeraj > Rottela ; Ankur Dwivedi > ; ciara.po...@intel.com; Stephen Hemminger > ; Yigit, Ferruh ; > bruce.richard...@intel.com > Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove > LIST_END enumerators > > 13/10/2021 07:36, Anoob Joseph: > > From: Thomas Monjalon > > > 12/10/2021 16:47, Kinsella, Ray: > > > > On 12/10/2021 15:18, Anoob Joseph wrote: > > > > > From: Thomas Monjalon > > > > >> 12/10/2021 15:38, Anoob Joseph: > > > > >>> From: Thomas Monjalon > > > > 12/10/2021 13:34, Anoob Joseph: > > > > > From: Kinsella, Ray > > > > >> On 12/10/2021 11:50, Anoob Joseph wrote: > > > > >>> From: Akhil Goyal > > > > > On 08/10/2021 21:45, Akhil Goyal wrote: > > > > >> Remove *_LIST_END enumerators from asymmetric > crypto > > > lib to > > > > >> avoid ABI breakage for every new addition in enums. > > > > >> > > > > >> Signed-off-by: Akhil Goyal > > > > >> --- > > > > >> -} else if (xform->xform_type >= > > > > > RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END > > > > >> +} else if (xform->xform_type > > > > > RTE_CRYPTO_ASYM_XFORM_ECPM > > > > [...] > > > > > > > > > > So I am not sure that this is an improvement. > > > > > > > > Indeed, it is not an improvement. > > > > > > > > > The cryptodev issue we had, was that _LIST_END was being > > > > > used to size arrays. > > > > > And that broke when new algorithms got added. Is that an > > > > > issue, in this > > > > >> case? > > > > > > > > Yes we did this same exercise for symmetric crypto enums > > > earlier. > > > > Asym enums were left as it was experimental at that point. > > > > They are still experimental, but thought of making this > > > > uniform throughout DPDK enums. > > > > > > > > > > > > > > I am not sure that swapping out _LIST_END, and then > > > > > littering the code with RTE_CRYPTO_ASYM_XFORM_ECPM > and > > > > > RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an > > > > improvement > > > > here. > > > > > > > > > > My 2c is that from an ABI PoV > > > RTE_CRYPTO_ASYM_OP_LIST_END is > > > > > not better or worse, than > > > > >> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE? > > > > > > > > > > Interested to hear other thoughts. > > > > > > > > I don’t have any better solution for avoiding ABI issues for > now. > > > > The change is for avoiding ABI breakage. But we can drop > > > > this patch For now as asym is still experimental. > > > > >>> > > > > >>> [Anoob] Having LIST_END would preclude new additions to > > > > >>> asymmetric > > > > algos? > > > > >> If yes, then I would suggest we address it now. > > > > >> > > > > >> Not at all - but it can be problematic, if two versions of > > > > >> DPDK disagree with the value of LIST_END. > > > > >> > > > > >>> Looking at the "problematic changes", we only have 2-3 > > > > >>> application & PMD changes. For unit test application, we > > > > >>> could may be do something like, > > > > >> > > > > >> The essental functionality not that different, I am just > > > > >> not sure that the verbosity below is helping. > > > > >> What you are really trying to guard against is people using > > > > >> LIST_END to size arrays. > > > > > > > > > > [Anoob] Our problem is application using LIST_END (which > > > > > comes from library) > > > > to determine the number of iterations for the loop. My > > > > suggestion is to modify the UT such that, we could use > > > > RTE_DIM(types) (which comes from application) to determine > > > > iterations of loop. This would solve the > > > > >> problem, right? > > > > > > > > The problem is not the application. > > > > Are you asking the app to define DPDK types? > > > > >>> > > > > >>> [Anoob] I didn't understand how you concluded that. > > > > >> > > > > >> Because you define a specific array in the test app. > > > > >> > > > > >>> The app is supposed to test "n" asymmetric features supported > > > > >>> by > > > DPDK. > > > > >> Currently, it does that by looping from 0 to LIST_END which > > > > >> happens to give you the first n f
Re: [dpdk-dev] [PATCH] mbuf: enforce no option for dynamic fields and flags
On 10/12/21 11:14 PM, Stephen Hemminger wrote:
> On Tue, 12 Oct 2021 21:39:57 +0200
> David Marchand wrote:
>
>> As stated in the API, dynamic field and flags should be created with no
>> additional flag (simply in the API for future changes).
>>
>> Fix the dynamic flag register helper which was not enforcing it and add
>> unit tests.
>>
>> Fixes: 4958ca3a443a ("mbuf: support dynamic fields and flags")
>>
>> Signed-off-by: David Marchand
>
> Acked-by: Stephen Hemminger
>
Acked-by: Andrew Rybchenko
Re: [dpdk-dev] [PATCH v6 1/6] ethdev: fix max Rx packet length
Hi, > -Original Message- > From: Yigit, Ferruh > Sent: Tuesday, October 12, 2021 7:54 > To: Jerin Jacob ; Li, Xiaoyun ; > Chas Williams ; Min Hu (Connor) ; > Hemant Agrawal ; Sachin Saxena > ; Zhang, Qi Z ; Wang, > Xiao W ; Matan Azrad ; > Viacheslav Ovsiienko ; Harman Kalra > ; Maciej Czekaj ; Ray Kinsella > ; Iremonger, Bernard ; > Ananyev, Konstantin ; Kiran Kumar K > ; Nithin Dabilpuram > ; Hunt, David ; > Mcnamara, John ; Richardson, Bruce > ; Igor Russkikh ; > Steven Webster ; Peters, Matt > ; Somalapuram Amaranath > ; Rasesh Mody ; Shahed > Shaikh ; Ajit Khaparde > ; Somnath Kotur > ; Sunil Kumar Kori ; > Satha Rao ; Rahul Lakkireddy > ; Wang, Haiyue ; > Marcin Wojtas ; Michal Krawczyk ; > Shai Brandes ; Evgeny Schemeilin > ; Igor Chauskin ; Gagandeep > Singh ; Daley, John ; Hyong Youb > Kim ; Ziyang Xuan ; > Xiaoyun Wang ; Guoyang Zhou > ; Yisen Zhuang ; > Lijun Ou ; Xing, Beilei ; Wu, > Jingjing ; Yang, Qiming ; > Andrew Boyer ; Xu, Rosen ; > Shijith Thotton ; Srisivasubramanian Srinivasan > ; Zyta Szpak ; Liron Himi > ; Heinrich Kuhn ; > Devendra Singh Rawat ; Andrew Rybchenko > ; Wiles, Keith ; > Jiawen Wu ; Jian Wang > ; Maxime Coquelin > ; Xia, Chenbo ; > Chautru, Nicolas ; Van Haaren, Harry > ; Dumitrescu, Cristian > ; Nicolau, Radu ; > Akhil Goyal ; Kantecki, Tomasz > ; Doherty, Declan ; > Pavan Nikhilesh ; Rybalchenko, Kirill > ; Singh, Jasvinder > ; Thomas Monjalon > Cc: Yigit, Ferruh ; dev@dpdk.org; Huisong Li > > Subject: [PATCH v6 1/6] ethdev: fix max Rx packet length > > There is a confusion on setting max Rx packet length, this patch aims to > clarify it. > > 'rte_eth_dev_configure()' API accepts max Rx packet size via > 'uint32_t max_rx_pkt_len' field of the config struct 'struct > rte_eth_conf'. > > Also 'rte_eth_dev_set_mtu()' API can be used to set the MTU, and result > stored into '(struct rte_eth_dev)->data->mtu'. > > These two APIs are related but they work in a disconnected way, they > store the set values in different variables which makes hard to figure > out which one to use, also having two different method for a related > functionality is confusing for the users. > > Other issues causing confusion is: > * maximum transmission unit (MTU) is payload of the Ethernet frame. And > 'max_rx_pkt_len' is the size of the Ethernet frame. Difference is > Ethernet frame overhead, and this overhead may be different from > device to device based on what device supports, like VLAN and QinQ. > * 'max_rx_pkt_len' is only valid when application requested jumbo frame, > which adds additional confusion and some APIs and PMDs already > discards this documented behavior. > * For the jumbo frame enabled case, 'max_rx_pkt_len' is an mandatory > field, this adds configuration complexity for application. > > As solution, both APIs gets MTU as parameter, and both saves the result > in same variable '(struct rte_eth_dev)->data->mtu'. For this > 'max_rx_pkt_len' updated as 'mtu', and it is always valid independent > from jumbo frame. > > For 'rte_eth_dev_configure()', 'dev->data->dev_conf.rxmode.mtu' is user > request and it should be used only within configure function and result > should be stored to '(struct rte_eth_dev)->data->mtu'. After that point > both application and PMD uses MTU from this variable. > > When application doesn't provide an MTU during 'rte_eth_dev_configure()' > default 'RTE_ETHER_MTU' value is used. > > Additional clarification done on scattered Rx configuration, in > relation to MTU and Rx buffer size. > MTU is used to configure the device for physical Rx/Tx size limitation, > Rx buffer is where to store Rx packets, many PMDs use mbuf data buffer > size as Rx buffer size. > PMDs compare MTU against Rx buffer size to decide enabling scattered Rx > or not. If scattered Rx is not supported by device, MTU bigger than Rx > buffer size should fail. > > Signed-off-by: Ferruh Yigit > Acked-by: Ajit Khaparde > Acked-by: Somnath Kotur > Acked-by: Huisong Li > --- > Cc: Min Hu (Connor) > > v2: > * Converted to explicit checks for zero/non-zero > * fixed hns3 checks > * fixed some sample app rxmode.mtu value > * fixed some sample app max-pkt-len argument and updated doc for it > > v3: > * rebased > > v4: > * fix typos in commit logs > > v5: > * fix testpmd '--max-pkt-len=###' parameter for DTS jumbo frame test > > v6: > * uint32_t type used in 'eth_dev_get_overhead_len()' helper function > --- Acked-by: Rosen Xu
Re: [dpdk-dev] [PATCH v6 4/6] ethdev: remove jumbo offload flag
wt., 12 paź 2021 o 01:54 Ferruh Yigit napisał(a): > > Removing 'DEV_RX_OFFLOAD_JUMBO_FRAME' offload flag. > > Instead of drivers announce this capability, application can deduct the > capability by checking reported 'dev_info.max_mtu' or > 'dev_info.max_rx_pktlen'. > > And instead of application setting this flag explicitly to enable jumbo > frames, this can be deduced by driver by comparing requested 'mtu' to > 'RTE_ETHER_MTU'. > > Removing this additional configuration for simplification. > > Suggested-by: Konstantin Ananyev > Signed-off-by: Ferruh Yigit > Acked-by: Andrew Rybchenko > Reviewed-by: Rosen Xu > Acked-by: Somnath Kotur > Acked-by: Konstantin Ananyev > Acked-by: Huisong Li > --- For net/ena: Acked-by: Michal Krawczyk Thanks, Michal
[dpdk-dev] [PATCH] examples/l2fwd: add promiscuous mode selection through command line option
The default behaviour of l2fwd is to exit if we are unable to turn
promiscuous mode on. On some aws instances turning promiscuous mode
on is not permitted. In such cases there should be a way to run the
application without promiscuous mode.
This patch allows user to turn promiscuous mode on via command line
parameter. l3fwd has a similar option available.
Signed-off-by: Sarosh Arif
---
.../sample_app_ug/l2_forward_real_virtual.rst | 4
examples/l2fwd/main.c | 23 +--
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
index 7b1529b2fa..ac1eab0b31 100644
--- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
+++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
@@ -92,6 +92,7 @@ The application requires a number of command line options:
.. code-block:: console
.//examples/dpdk-l2fwd [EAL options] -- -p PORTMASK
+ [-P]
[-q NQ]
--[no-]mac-updating
[--portmap="(port, port)[,(port, port)]"]
@@ -100,6 +101,9 @@ where,
* p PORTMASK: A hexadecimal bitmask of the ports to configure
+* P: Optional, sets all ports to promiscuous mode so that packets are
accepted regardless of the packet's Ethernet MAC destination address.
+ Without this option, only packets with the Ethernet MAC destination address
set to the Ethernet address of the port are accepted.
+
* q NQ: A number of queues (=ports) per lcore (default is 1)
* --[no-]mac-updating: Enable or disable MAC addresses updating (enabled by
default)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index f3deeba0a6..ce56cef863 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -44,6 +44,9 @@ static volatile bool force_quit;
/* MAC updating enabled by default */
static int mac_updating = 1;
+/* Ports set in promiscuous mode off by default. */
+static int promiscuous_on;
+
#define RTE_LOGTYPE_L2FWD RTE_LOGTYPE_USER1
#define MAX_PKT_BURST 32
@@ -307,8 +310,9 @@ l2fwd_launch_one_lcore(__rte_unused void *dummy)
static void
l2fwd_usage(const char *prgname)
{
- printf("%s [EAL options] -- -p PORTMASK [-q NQ]\n"
+ printf("%s [EAL options] -- -p PORTMASK [-P] [-q NQ]\n"
" -p PORTMASK: hexadecimal bitmask of ports to configure\n"
+ " -P : Enable promiscuous mode\n"
" -q NQ: number of queue (=ports) per lcore (default is 1)\n"
" -T PERIOD: statistics will be refreshed each PERIOD seconds
(0 to disable, 10 default, 86400 maximum)\n"
" --no-mac-updating: Disable MAC addresses updating (enabled by
default)\n"
@@ -425,6 +429,7 @@ l2fwd_parse_timer_period(const char *q_arg)
static const char short_options[] =
"p:" /* portmask */
+ "P" /* promiscuous */
"q:" /* number of queues */
"T:" /* timer period */
;
@@ -473,6 +478,9 @@ l2fwd_parse_args(int argc, char **argv)
return -1;
}
break;
+ case 'P':
+ promiscuous_on = 1;
+ break;
/* nqueue */
case 'q':
@@ -872,12 +880,13 @@ main(int argc, char **argv)
ret, portid);
printf("done: \n");
-
- ret = rte_eth_promiscuous_enable(portid);
- if (ret != 0)
- rte_exit(EXIT_FAILURE,
-"rte_eth_promiscuous_enable:err=%s, port=%u\n",
-rte_strerror(-ret), portid);
+ if (promiscuous_on) {
+ ret = rte_eth_promiscuous_enable(portid);
+ if (ret != 0)
+ rte_exit(EXIT_FAILURE,
+ "rte_eth_promiscuous_enable:err=%s,
port=%u\n",
+ rte_strerror(-ret), portid);
+ }
printf("Port %u, MAC address: " RTE_ETHER_ADDR_PRT_FMT "\n\n",
portid,
--
2.25.1
Re: [dpdk-dev] [PATCH v25 1/6] dmadev: introduce DMA device library
13/10/2021 02:21, fengchengwen:
> On 2021/10/13 3:09, Thomas Monjalon wrote:
> > 11/10/2021 09:33, Chengwen Feng:
> >> +static void
> >> +dma_release(struct rte_dma_dev *dev)
> >> +{
> >> + rte_free(dev->dev_private);
> >> + memset(dev, 0, sizeof(struct rte_dma_dev));
> >> +}
[...]
> >> +int
> >> +rte_dma_pmd_release(const char *name)
> >> +{
> >> + struct rte_dma_dev *dev;
> >> +
> >> + if (dma_check_name(name) != 0)
> >> + return -EINVAL;
> >> +
> >> + dev = dma_find_by_name(name);
> >> + if (dev == NULL)
> >> + return -EINVAL;
> >> +
> >> + dma_release(dev);
> >> + return 0;
> >> +}
> >
> > Trying to understand the logic of creation/destroy.
> > skeldma_probe
> > \-> skeldma_create
> > \-> rte_dma_pmd_allocate
> > \-> dma_allocate
> > \-> dma_data_prepare
> > \-> dma_dev_data_prepare
> > skeldma_remove
> > \-> skeldma_destroy
> > \-> rte_dma_pmd_release
> > \-> dma_release
>
> This patch only provide device allocate function, the 2st patch provide extra
> logic:
>
> diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
> index 42a4693bd9..a6a5680d2b 100644
> --- a/lib/dmadev/rte_dmadev.c
> +++ b/lib/dmadev/rte_dmadev.c
> @@ -201,6 +201,9 @@ rte_dma_pmd_release(const char *name)
> if (dev == NULL)
> return -EINVAL;
>
> + if (dev->state == RTE_DMA_DEV_READY)
> + return rte_dma_close(dev->dev_id);
> +
> dma_release(dev);
> return 0;
>}
>
> So the skeldma remove will be:
>
> skeldma_remove
> \-> skeldma_destroy
> \-> rte_dma_pmd_release
> \-> rte_dma_close
> \-> dma_release
OK, in this case, no need to dma_release from rte_dma_pmd_release,
because it is already called from rte_dma_close.
[dpdk-dev] [dpdk-users] DPDK VF rte_flow invalid - Cannot create flow on VF
Hi, I am trying to create some flow rules on VF using DPDK 19.08 rte_flow API. But it returns -38, *Function not implemented* when I called rte_flow_validate(). I bind I40E on PF0 and vfio-pci on VF0 and iavf on VF1 and VF2 I just wanna know can X710's VF create flow rules using rte_flow. Should I set any flags or call any functions to open this ?
[dpdk-dev] [PATCH v5] ethdev: replace bit shifts with macros
The macros RTE_BIT32 and RTE_BIT64 are used to replace bit shifts.
The macro UINT64C is also used to replace remaining occurrences of ULL.
The bit shifts of ETH_RSS_LEVEL_* are kept for aesthetic reason.
The API of rte_mtr and rte_tm is using enums for 64-bit variables.
As they are enums, unsigned bit cannot be used.
Signed-off-by: Thomas Monjalon
Reviewed-by: Andrew Rybchenko
---
v2: use RTE_BIT32 in enums
v3: rebase on main
v4: keep enums untouched
v5: convert new flag ETH_RSS_L4_CHKSUM
---
lib/ethdev/rte_ethdev.c | 16 ++---
lib/ethdev/rte_ethdev.h | 131
lib/ethdev/rte_flow.c | 4 +-
lib/ethdev/rte_flow.h | 6 +-
4 files changed, 79 insertions(+), 78 deletions(-)
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 028907bc4b..8c6af2c240 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -1317,7 +1317,7 @@ eth_dev_validate_offloads(uint16_t port_id, uint64_t
req_offloads,
while (offloads_diff != 0) {
/* Check if any offload is requested but not enabled. */
- offload = 1ULL << __builtin_ctzll(offloads_diff);
+ offload = RTE_BIT64(__builtin_ctzll(offloads_diff));
if (offload & req_offloads) {
RTE_ETHDEV_LOG(ERR,
"Port %u failed to enable %s offload %s\n",
@@ -1683,7 +1683,7 @@ eth_dev_mac_restore(struct rte_eth_dev *dev,
pool_mask = dev->data->mac_pool_sel[i];
do {
- if (pool_mask & 1ULL)
+ if (pool_mask & UINT64_C(1))
(*dev->dev_ops->mac_addr_add)(dev,
addr, i, pool);
pool_mask >>= 1;
@@ -1959,7 +1959,7 @@ rte_eth_rx_queue_check_split(const struct
rte_eth_rxseg_split *rx_seg,
* for each segment specified in extended configuration.
*/
mp_first = rx_seg[0].mp;
- offset_mask = (1u << seg_capa->offset_align_log2) - 1;
+ offset_mask = RTE_BIT32(seg_capa->offset_align_log2) - 1;
for (seg_idx = 0; seg_idx < n_seg; seg_idx++) {
struct rte_mempool *mpl = rx_seg[seg_idx].mp;
uint32_t length = rx_seg[seg_idx].length;
@@ -3666,9 +3666,9 @@ rte_eth_dev_vlan_filter(uint16_t port_id, uint16_t
vlan_id, int on)
vbit = vlan_id % 64;
if (on)
- vfc->ids[vidx] |= UINT64_C(1) << vbit;
+ vfc->ids[vidx] |= RTE_BIT64(vbit);
else
- vfc->ids[vidx] &= ~(UINT64_C(1) << vbit);
+ vfc->ids[vidx] &= ~RTE_BIT64(vbit);
}
return eth_err(port_id, ret);
@@ -3940,7 +3940,7 @@ eth_check_reta_entry(struct rte_eth_rss_reta_entry64
*reta_conf,
for (i = 0; i < reta_size; i++) {
idx = i / RTE_RETA_GROUP_SIZE;
shift = i % RTE_RETA_GROUP_SIZE;
- if ((reta_conf[idx].mask & (1ULL << shift)) &&
+ if ((reta_conf[idx].mask & RTE_BIT64(shift)) &&
(reta_conf[idx].reta[shift] >= max_rxq)) {
RTE_ETHDEV_LOG(ERR,
"reta_conf[%u]->reta[%u]: %u exceeds the
maximum rxq index: %u\n",
@@ -4279,7 +4279,7 @@ rte_eth_dev_mac_addr_add(uint16_t port_id, struct
rte_ether_addr *addr,
pool_mask = dev->data->mac_pool_sel[index];
/* Check if both MAC address and pool is already there, and do
nothing */
- if (pool_mask & (1ULL << pool))
+ if (pool_mask & RTE_BIT64(pool))
return 0;
}
@@ -4291,7 +4291,7 @@ rte_eth_dev_mac_addr_add(uint16_t port_id, struct
rte_ether_addr *addr,
rte_ether_addr_copy(addr, &dev->data->mac_addrs[index]);
/* Update pool bitmap in NIC data structure */
- dev->data->mac_pool_sel[index] |= (1ULL << pool);
+ dev->data->mac_pool_sel[index] |= RTE_BIT64(pool);
}
return eth_err(port_id, ret);
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 6d80514ba7..8ebc22efdd 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -159,6 +159,7 @@ extern "C" {
#include
#include
#include
+#include
#include
#include
#include
@@ -279,23 +280,23 @@ struct rte_eth_stats {
/**@{@name Link speed capabilities
* Device supported speeds bitmap flags
*/
-#define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all speeds) */
-#define ETH_LINK_SPEED_FIXED(1 << 0) /**< Disable autoneg (fixed speed)
*/
-#define ETH_LINK_SPEED_10M_HD (1 << 1) /**< 10 Mbps half-duplex */
-#define ETH_LINK_SPEED_10M (1 << 2) /**< 10 Mbps full-duplex */
-#define ETH_LINK_SPEED_100M_HD (1 << 3) /**< 100 Mbps half-duplex */
-#define
[dpdk-dev] [PATCH v4] eventdev/rx_adapter: add telemetry callbacks
Added telemetry callbacks to get Rx adapter stats, reset stats and
to get Rx queue config information.
Acked-by: Jay Jayatheerthan
Signed-off-by: Ganapati Kundapura
---
v4:
* Addressed segfault when per Rx queue event buffer is used.
v3:
* Updated release notes.
* Addressed review comments.
v2:
* Fixed checkpatch warning.
---
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index dfc2cbd..9955e52 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -130,6 +130,10 @@ New Features
* Added tests to validate packets hard expiry.
* Added tests to verify tunnel header verification in IPsec inbound.
+* **Updated rte_event_eth_rx_adapter_stats structure
+ * Added 'uint64_t rx_event_buf_count'
+ * Added 'uint64_t rx_event_buf_size'
+
Removed Items
-
diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
b/lib/eventdev/rte_event_eth_rx_adapter.c
index 9ac976c..bd68b8e 100644
--- a/lib/eventdev/rte_event_eth_rx_adapter.c
+++ b/lib/eventdev/rte_event_eth_rx_adapter.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "rte_eventdev.h"
#include "eventdev_pmd.h"
@@ -2852,6 +2853,7 @@ rte_event_eth_rx_adapter_stats_get(uint8_t id,
struct rte_event_eth_rx_adapter_stats *stats)
{
struct rte_event_eth_rx_adapter *rx_adapter;
+ struct rte_eth_event_enqueue_buffer *buf;
struct rte_event_eth_rx_adapter_stats dev_stats_sum = { 0 };
struct rte_event_eth_rx_adapter_stats dev_stats;
struct rte_eventdev *dev;
@@ -2890,6 +2892,15 @@ rte_event_eth_rx_adapter_stats_get(uint8_t id,
stats->rx_packets += dev_stats_sum.rx_packets;
stats->rx_enq_count += dev_stats_sum.rx_enq_count;
+ if (!rx_adapter->use_queue_event_buf) {
+ buf = &rx_adapter->event_enqueue_buffer;
+ stats->rx_event_buf_count = buf->count;
+ stats->rx_event_buf_size = buf->events_size;
+ } else {
+ stats->rx_event_buf_count = 0;
+ stats->rx_event_buf_size = 0;
+ }
+
return 0;
}
@@ -3052,3 +3063,146 @@ rte_event_eth_rx_adapter_queue_conf_get(uint8_t id,
return 0;
}
+
+#define RXA_ADD_DICT(stats, s) rte_tel_data_add_dict_u64(d, #s, stats.s)
+
+static int
+handle_rxa_stats(const char *cmd __rte_unused,
+const char *params,
+struct rte_tel_data *d)
+{
+ uint8_t rx_adapter_id;
+ struct rte_event_eth_rx_adapter_stats rx_adptr_stats;
+
+ if (params == NULL || strlen(params) == 0 || !isdigit(*params))
+ return -1;
+
+ /* Get Rx adapter ID from parameter string */
+ rx_adapter_id = atoi(params);
+ RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(rx_adapter_id, -EINVAL);
+
+ /* Get Rx adapter stats */
+ if (rte_event_eth_rx_adapter_stats_get(rx_adapter_id,
+ &rx_adptr_stats)) {
+ RTE_EDEV_LOG_ERR("Failed to get Rx adapter stats\n");
+ return -1;
+ }
+
+ rte_tel_data_start_dict(d);
+ rte_tel_data_add_dict_u64(d, "rx_adapter_id", rx_adapter_id);
+ RXA_ADD_DICT(rx_adptr_stats, rx_packets);
+ RXA_ADD_DICT(rx_adptr_stats, rx_poll_count);
+ RXA_ADD_DICT(rx_adptr_stats, rx_dropped);
+ RXA_ADD_DICT(rx_adptr_stats, rx_enq_retry);
+ RXA_ADD_DICT(rx_adptr_stats, rx_event_buf_count);
+ RXA_ADD_DICT(rx_adptr_stats, rx_event_buf_size);
+ RXA_ADD_DICT(rx_adptr_stats, rx_enq_count);
+ RXA_ADD_DICT(rx_adptr_stats, rx_enq_start_ts);
+ RXA_ADD_DICT(rx_adptr_stats, rx_enq_block_cycles);
+ RXA_ADD_DICT(rx_adptr_stats, rx_enq_end_ts);
+ RXA_ADD_DICT(rx_adptr_stats, rx_intr_packets);
+
+ return 0;
+}
+
+static int
+handle_rxa_stats_reset(const char *cmd __rte_unused,
+ const char *params,
+ struct rte_tel_data *d __rte_unused)
+{
+ uint8_t rx_adapter_id;
+
+ if (params == NULL || strlen(params) == 0 || ~isdigit(*params))
+ return -1;
+
+ /* Get Rx adapter ID from parameter string */
+ rx_adapter_id = atoi(params);
+ RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(rx_adapter_id, -EINVAL);
+
+ /* Reset Rx adapter stats */
+ if (rte_event_eth_rx_adapter_stats_reset(rx_adapter_id)) {
+ RTE_EDEV_LOG_ERR("Failed to reset Rx adapter stats\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+static int
+handle_rxa_get_queue_conf(const char *cmd __rte_unused,
+ const char *params,
+ struct rte_tel_data *d)
+{
+ uint8_t rx_adapter_id;
+ uint16_t rx_queue_id;
+ int eth_dev_id;
+ char *token, *l_params;
+ struct rte_event_eth_rx_adapter_queue_conf queue_conf;
+
+ if (params == NULL || strlen(params) == 0 || !isdigit(*params))
Re: [dpdk-dev] [PATCH] doc: remove web references to internal guides
08/10/2021 09:34, David Marchand: > On Thu, Oct 7, 2021 at 2:22 PM Thomas Monjalon wrote: > > > > The guides should be referenced locally with RST syntax > > :doc: (beginning of page) or :ref: (specific chapter). > > The links to doc.dpdk.org/guides/ are removed. > > > > The links to the doc.dpdk.org/api/ are acceptable, > > but should not point to a specific version, so one is fixed. > > > > Signed-off-by: Thomas Monjalon > > Acked-by: David Marchand Applied
Re: [dpdk-dev] [PATCH v6 1/2] Enable ASan for memory detector on DPDK
On Thu, Sep 30, 2021 at 10:20:00AM +0200, David Marchand wrote:
> Hello,
>
> I see v6 is superseded in pw, I have been cleaning my queue... maybe my fault.
>
>
> On Thu, Sep 30, 2021 at 7:37 AM wrote:
> >
> > From: Zhihong Peng
> >
> > AddressSanitizer (ASan) is a google memory error detect
> > standard tool. It could help to detect use-after-free and
> > {heap,stack,global}-buffer overflow bugs in C/C++ programs,
> > print detailed error information when error happens, large
> > improve debug efficiency.
> >
> > `AddressSanitizer
> > ` (ASan)
> > is a widely-used debugging tool to detect memory access errors.
> > It helps detect issues like use-after-free, various kinds of buffer
> > overruns in C/C++ programs, and other similar errors, as well as
> > printing out detailed debug information whenever an error is detected.
>
> This patch mixes how to use ASan and instrumenting the DPDK mem allocator.
>
> I would split this patch in two.
>
> The first patch can add the documentation on enabling/using ASan and
> describe the known issues on enabling it.
> I'd find it better (from a user pov) if we hide all those details
> about b_lundef and installation of libasan on Centos.
>
> Something like (only quickly tested):
>
> diff --git a/config/meson.build b/config/meson.build
> index 4cdf589e20..7d8b71da79 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -411,6 +411,33 @@ if get_option('b_lto')
> endif
> endif
>
> +if get_option('b_sanitize') == 'address'
> +asan_dep = cc.find_library('asan', required: true)
> +if (not cc.links('int main(int argc, char *argv[]) { return 0; }',
> + dependencies: asan_dep))
> +error('broken dependency, "libasan"')
> +endif
> +add_project_link_arguments('-lasan', language: 'c')
> +dpdk_extra_ldflags += '-lasan'
> +endif
> +
> if get_option('default_library') == 'both'
> error( '''
> Unsupported value "both" for "default_library" option.
>
>
> Bruce, do you see an issue with this approach?
>
Apologies for delayed reply on this.
No issue with this approach on my end, seems reasonable. Just watch out
that b_sanitize can have "address,undefined" as a possible value, so if we
want to support that, we can't just check directly for the literal string
"address"
>
> Then a second patch adds the rte_malloc instrumentation, with a check
> at configuration time.
>
> endif
> add_project_link_arguments('-lasan', language: 'c')
> dpdk_extra_ldflags += '-lasan'
> +if arch_subdir == 'x86'
> +asan_check_code = '''
> +#ifdef __SANITIZE_ADDRESS__
> +#define RTE_MALLOC_ASAN
> +#elif defined(__has_feature)
> +# if __has_feature(address_sanitizer)
> +#define RTE_MALLOC_ASAN
> +# endif
> +#endif
> +
> +#ifndef RTE_MALLOC_ASAN
> +#error ASan not available.
> +#endif
> +'''
> +if cc.compiles(asan_check_code)
> +dpdk_conf.set10('RTE_MALLOC_ASAN', true)
> +endif
> +endif
> endif
>
Apologies, but I haven't been tracking this set in much detail.
Do we really need this second configuration check? Should it, or could it,
be merged into the check above for the asan library presence?
/Bruce
[dpdk-dev] [PATCH v1 0/1] ci: enable DPDK GHA for arm64 with self-hosted runners
This is to enable DPDK GitHub Actions on arm64 and CI jobs are triggered only for repos installed with given GHApp and runners. Serena He (1): ci: enable DPDK GHA for arm64 with self-hosted runners .github/workflows/build-arm64.yml | 118 ++ 1 file changed, 118 insertions(+) create mode 100644 .github/workflows/build-arm64.yml -- 2.17.1
[dpdk-dev] [PATCH v1 1/1] ci: enable DPDK GHA for arm64 with self-hosted runners
CI jobs are triggered only for repos installed with given GHApp and runners
Cc: sta...@dpdk.org
Signed-off-by: Serena He
---
.github/workflows/build-arm64.yml | 118 ++
1 file changed, 118 insertions(+)
create mode 100644 .github/workflows/build-arm64.yml
diff --git a/.github/workflows/build-arm64.yml
b/.github/workflows/build-arm64.yml
new file mode 100644
index 00..570563f7c8
--- /dev/null
+++ b/.github/workflows/build-arm64.yml
@@ -0,0 +1,118 @@
+name: build-arm64
+
+on:
+ push:
+ schedule:
+- cron: '0 0 * * 1'
+
+defaults:
+ run:
+shell: bash --noprofile --norc -exo pipefail {0}
+
+jobs:
+ build:
+# Here, runners for arm64 are accessed by installed GitHub APP, thus will
not be available by fork.
+# you can change the following 'if' and 'runs-on' if you have your own
runners installed.
+# or request to get your repo on the whitelist to use GitHub APP and
delete this 'if'.
+if: ${{ github.repository == 'DPDK/dpdk' || github.repository ==
'ovsrobot/dpdk' }}
+name: ${{ join(matrix.config.*, '-') }}
+runs-on: ${{ matrix.config.os }}
+env:
+ ABI_CHECKS: ${{ contains(matrix.config.checks, 'abi') }}
+ BUILD_DOCS: ${{ contains(matrix.config.checks, 'doc') }}
+ CL: ${{ matrix.config.compiler == 'clang' }}
+ CC: ccache ${{ matrix.config.compiler }}
+ DEF_LIB: ${{ matrix.config.library }}
+ LIBABIGAIL_VERSION: libabigail-1.8
+ REF_GIT_TAG: none
+
+strategy:
+ fail-fast: false
+ matrix:
+config:
+ - os: [self-hosted,arm-ubuntu-20.04]
+compiler: gcc
+library: static
+ - os: [self-hosted,arm-ubuntu-20.04]
+compiler: gcc
+library: shared
+checks: doc+tests
+ - os: [self-hosted,arm-ubuntu-20.04]
+compiler: clang
+library: static
+ - os: [self-hosted,arm-ubuntu-20.04]
+compiler: clang
+library: shared
+checks: doc+tests
+
+steps:
+- name: Checkout sources
+ uses: actions/checkout@v2
+- name: Generate cache keys
+ id: get_ref_keys
+ run: |
+echo -n '::set-output name=ccache::'
+echo 'ccache-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{
matrix.config.cross }}-'$(date -u +%Y-w%W)
+echo -n '::set-output name=libabigail::'
+echo 'libabigail-${{ matrix.config.os }}'
+echo -n '::set-output name=abi::'
+echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{
matrix.config.cross }}-${{ env.LIBABIGAIL_VERSION }}-${{ env.REF_GIT_TAG }}'
+- name: Retrieve ccache cache
+ uses: actions/cache@v2
+ with:
+path: ~/.ccache
+key: ${{ steps.get_ref_keys.outputs.ccache }}-${{ github.ref }}
+restore-keys: |
+ ${{ steps.get_ref_keys.outputs.ccache }}-refs/heads/main
+- name: Retrieve libabigail cache
+ id: libabigail-cache
+ uses: actions/cache@v2
+ if: env.ABI_CHECKS == 'true'
+ with:
+path: libabigail
+key: ${{ steps.get_ref_keys.outputs.libabigail }}
+- name: Retrieve ABI reference cache
+ uses: actions/cache@v2
+ if: env.ABI_CHECKS == 'true'
+ with:
+path: reference
+key: ${{ steps.get_ref_keys.outputs.abi }}
+- name: Update APT cache
+ run: sudo apt update || true
+- name: Install packages
+ run: sudo apt install -y ccache libnuma-dev python3-setuptools
+python3-wheel python3-pip python3-pyelftools ninja-build libbsd-dev
+libpcap-dev libibverbs-dev libcrypto++-dev libfdt-dev libjansson-dev
+libarchive-dev zlib1g-dev pkgconf
+- name: Install libabigail build dependencies if no cache is available
+ if: env.ABI_CHECKS == 'true' && steps.libabigail-cache.outputs.cache-hit
!= 'true'
+ run: sudo apt install -y autoconf automake libtool pkg-config libxml2-dev
+ libdw-dev
+
+- name: Install test tools packages
+ run: sudo apt install -y gdb
+- name: Install doc generation packages
+ if: env.BUILD_DOCS == 'true'
+ run: sudo apt install -y doxygen graphviz python3-sphinx
+python3-sphinx-rtd-theme
+- name: Run setup
+ run: |
+.ci/linux-setup.sh
+# Workaround on $HOME permissions as EAL checks them for plugin loading
+chmod o-w $HOME
+- name: Install clang
+ if: env.CL == 'true'
+ run: sudo apt install -y clang
+- name: Build and test
+ run: .ci/linux-build.sh
+- name: Upload logs on failure
+ if: failure()
+ uses: actions/upload-artifact@v2
+ with:
+name: meson-logs-${{ join(matrix.config.*, '-') }}
+path: |
+ build/meson-logs/testlog.txt
+ build/.ninja_log
+ build/meson-logs/meson-log.txt
+ build/gdb.log
+
--
2.17.1
[dpdk-dev] [PATCH] net/hns3: fix incorrect free function
From: Chengwen Feng
The intr_handle->intr_vec is allocated by rte_zmalloc(), but freed by
free(), this patch fixes it.
Fixes: 02a7b55657b2 ("net/hns3: support Rx interrupt")
Cc: sta...@dpdk.org
Signed-off-by: Chengwen Feng
---
drivers/net/hns3/hns3_ethdev_vf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c
b/drivers/net/hns3/hns3_ethdev_vf.c
index f3cc190d1c..e896de58a4 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -2358,7 +2358,7 @@ hns3vf_map_rx_interrupt(struct rte_eth_dev *dev)
return 0;
vf_bind_vector_error:
- free(intr_handle->intr_vec);
+ rte_free(intr_handle->intr_vec);
intr_handle->intr_vec = NULL;
vf_alloc_intr_vec_error:
rte_intr_efd_disable(intr_handle);
--
2.33.0
Re: [dpdk-dev] [PATCH 1/3] ethdev: introduce flow pre-configuration hints
On Tue, Oct 5, 2021 at 9:48 PM Alexander Kozyrev wrote:
>
> The flow rules creation/destruction at a large scale incurs a performance
> penalty and may negatively impact the packet processing when used
> as part of the datapath logic. This is mainly because software/hardware
> resources are allocated and prepared during the flow rule creation.
>
> In order to optimize the insertion rate, PMD may use some hints provided
> by the application at the initialization phase. The rte_flow_configure()
> function allows to pre-allocate all the needed resources beforehand.
> These resources can be used at a later stage without costly allocations.
> Every PMD may use only the subset of hints and ignore unused ones.
This could get tricky. An application can avoid attempts to create
flows for items/actions if it can get a hint that PMD cannot satisfy
some of the hints provided.
Also what if the application tries to configure a higher count than
what the PMD/HW can support?
It will be good if the hints can be negotiated.
Something like this?
Application could start with a set of hints.
PMD can check what can be supported and return an updated set.
Application stays within those values till it needs to resize.
>
> Signed-off-by: Alexander Kozyrev
> Suggested-by: Ori Kam
> ---
> lib/ethdev/rte_flow.h | 70 +++
> 1 file changed, 70 insertions(+)
>
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index 7b1ed7f110..c69d503b90 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -4288,6 +4288,76 @@ rte_flow_tunnel_item_release(uint16_t port_id,
> struct rte_flow_item *items,
> uint32_t num_of_items,
> struct rte_flow_error *error);
> +
> +/**
> + * Flow engine configuration.
> + */
> +__extension__
> +struct rte_flow_port_attr {
> + /**
> +* Version of the struct layout, should be 0.
> +*/
> + uint32_t version;
> + /**
> +* Memory size allocated for the flow rules management.
> +* If set to 0, memory is allocated dynamically.
> +*/
> + uint32_t mem_size;
> + /**
> +* Number of counter actions pre-configured.
> +* If set to 0, PMD will allocate counters dynamically.
> +* @see RTE_FLOW_ACTION_TYPE_COUNT
> +*/
> + uint32_t nb_counters;
> + /**
> +* Number of aging actions pre-configured.
> +* If set to 0, PMD will allocate aging dynamically.
> +* @see RTE_FLOW_ACTION_TYPE_AGE
> +*/
> + uint32_t nb_aging;
> + /**
> +* Number of traffic metering actions pre-configured.
> +* If set to 0, PMD will allocate meters dynamically.
> +* @see RTE_FLOW_ACTION_TYPE_METER
> +*/
> + uint32_t nb_meters;
> + /**
> +* Resources reallocation strategy.
> +* If set to 1, PMD is not allowed to allocate more resources on
> demand.
> +* An application can only allocate more resources by calling the
> +* configure API again with new values (may not be supported by PMD).
> +*/
> + uint32_t fixed_resource_size:1;
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Configure flow rules module.
> + * To pre-allocate resources as per the flow port attributes,
> + * this configuration function must be called before any flow rule is
> created.
> + * No other rte_flow function should be called while this function is
> invoked.
> + * This function can be called again to change the configuration.
> + * Some PMDs may not support re-configuration at all,
> + * or may only allow increasing the number of resources allocated.
> + *
> + * @param port_id
> + * Port identifier of Ethernet device.
> + * @param[in] port_attr
> + * Port configuration attributes.
> + * @param[out] error
> + * Perform verbose error reporting if not NULL.
> + * PMDs initialize this structure in case of error only.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +__rte_experimental
> +int
> +rte_flow_configure(uint16_t port_id,
> + const struct rte_flow_port_attr *port_attr,
> + struct rte_flow_error *error);
> #ifdef __cplusplus
> }
> #endif
> --
> 2.18.2
>
Re: [dpdk-dev] [PATCH v3] eventdev/rx_adapter: add telemetry callbacks
Hi Harish,
> -Original Message-
> From: Naga Harish K, S V
> Sent: 13 October 2021 12:18
> To: Kundapura, Ganapati ; Jayatheerthan, Jay
> ; jerinjac...@gmail.com; dev@dpdk.org
> Cc: Kinsella, Ray ; Thomas Monjalon
> ; David Marchand
> Subject: RE: [PATCH v3] eventdev/rx_adapter: add telemetry callbacks
>
>
>
> > -Original Message-
> > From: Kundapura, Ganapati
> > Sent: Tuesday, October 12, 2021 9:44 PM
> > To: Naga Harish K, S V ; Jayatheerthan,
> > Jay ; jerinjac...@gmail.com; dev@dpdk.org
> > Cc: Kinsella, Ray ; Thomas Monjalon
> > ; David Marchand
> > Subject: RE: [PATCH v3] eventdev/rx_adapter: add telemetry callbacks
> >
> > Hi Harish,
> >
> > > -Original Message-
> > > From: Naga Harish K, S V
> > > Sent: 12 October 2021 19:36
> > > To: Jayatheerthan, Jay ; Kundapura,
> > > Ganapati ; jerinjac...@gmail.com;
> > > dev@dpdk.org
> > > Cc: Kinsella, Ray ; Thomas Monjalon
> > > ; David Marchand
> >
> > > Subject: RE: [PATCH v3] eventdev/rx_adapter: add telemetry callbacks
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: dev On Behalf Of Jayatheerthan, Jay
> > > > Sent: Tuesday, October 12, 2021 6:39 PM
> > > > To: Kundapura, Ganapati ;
> > > > jerinjac...@gmail.com; dev@dpdk.org
> > > > Cc: Kinsella, Ray ; Thomas Monjalon
> > > > ; David Marchand
> >
> > > > Subject: Re: [dpdk-dev] [PATCH v3] eventdev/rx_adapter: add
> > > > telemetry callbacks
> > > >
> > > > Acked by: Jay Jayatheerthan
> > > >
> > > > + @Ray Kinsella @Thomas Monjalon @David Marchand
> > > >
> > > > > -Original Message-
> > > > > From: Kundapura, Ganapati
> > > > > Sent: Tuesday, October 12, 2021 3:55 PM
> > > > > To: jerinjac...@gmail.com; dev@dpdk.org
> > > > > Cc: Jayatheerthan, Jay
> > > > > Subject: [PATCH v3] eventdev/rx_adapter: add telemetry callbacks
> > > > >
> > > > > Added telemetry callbacks to get Rx adapter stats, reset stats
> > > > > and to get Rx queue config information.
> > > > >
> > > > > Signed-off-by: Ganapati Kundapura
> > > > > ---
> > > > > v3:
> > > > > * Updated release notes
> > > > > * Addressed review comments
> > > > >
> > > > > v2:
> > > > > * Fixed checkpatch warning
> > > > > ---
> > > > >
> > > > > diff --git a/doc/guides/rel_notes/release_21_11.rst
> > > > > b/doc/guides/rel_notes/release_21_11.rst
> > > > > index dfc2cbd..9955e52 100644
> > > > > --- a/doc/guides/rel_notes/release_21_11.rst
> > > > > +++ b/doc/guides/rel_notes/release_21_11.rst
> > > > > @@ -130,6 +130,10 @@ New Features
> > > > >* Added tests to validate packets hard expiry.
> > > > >* Added tests to verify tunnel header verification in IPsec
> > > > > inbound.
> > > > >
> > > > > +* **Updated rte_event_eth_rx_adapter_stats structure
> > > > > + * Added 'uint64_t rx_event_buf_count'
> > > > > + * Added 'uint64_t rx_event_buf_size'
> > > > > +
> > > > >
> > > > > Removed Items
> > > > > -
> > > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > index 9ac976c..7e3bf62 100644
> > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > @@ -18,6 +18,7 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > >
> > > > > #include "rte_eventdev.h"
> > > > > #include "eventdev_pmd.h"
> > > > > @@ -2852,6 +2853,7 @@ rte_event_eth_rx_adapter_stats_get(uint8_t
> > id,
> > > > > struct rte_event_eth_rx_adapter_stats
> > > > > *stats) {
> > > > > struct rte_event_eth_rx_adapter *rx_adapter;
> > > > > + struct rte_eth_event_enqueue_buffer *buf;
> > > > > struct rte_event_eth_rx_adapter_stats dev_stats_sum = { 0 };
> > > > > struct rte_event_eth_rx_adapter_stats dev_stats;
> > > > > struct rte_eventdev *dev;
> > > > > @@ -2887,8 +2889,11 @@
> > rte_event_eth_rx_adapter_stats_get(uint8_t
> > > > id,
> > > > > if (rx_adapter->service_inited)
> > > > > *stats = rx_adapter->stats;
> > > > >
> > > > > + buf = &rx_adapter->event_enqueue_buffer;
> > > > > stats->rx_packets += dev_stats_sum.rx_packets;
> > > > > stats->rx_enq_count += dev_stats_sum.rx_enq_count;
> > > > > + stats->rx_event_buf_count = buf->count;
> > >
> > > When per Rx queue event buffer is used, there is a possibility of
> > > segfault here Because of null pointer deference.
> > >
> > Queue_id is not passed to rte_event_eth_rx_adapter_stats_get() and
> > there's no way to retrieve the queue id to return the queue's event
> > buffer size and count. We may need to loop through all the queue's in
> > the adapter which requires changes in rte_event_eth_rx_adapter_stats
> > structure to hold event buffer size and count for all the queues.
> >
> > Alternatively stats_get() can return event buffer size and count only
> > if use_queue_event_buf = false i.e only for adapter wide event buffer.
> >
>
> This approach looks ok. When use_queue_e
Re: [dpdk-dev] [PATCH v2 2/3] app/testpmd: support PPPoL2TPv2oUDP RSS Hash
> -Original Message-
> From: Ori Kam
> Sent: Tuesday, October 12, 2021 11:32 PM
> To: Wang, Jie1X ; dev@dpdk.org
> Cc: Yigit, Ferruh ; NBU-Contact-Thomas Monjalon
> ; andrew.rybche...@oktetlabs.ru; Li, Xiaoyun
> ; Yang, SteveX ; Wu, Jingjing
> ; Xing, Beilei ; Wu, Wenjun1
>
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] app/testpmd: support PPPoL2TPv2oUDP
> RSS Hash
>
> Hi Jie,
>
> > -Original Message-
> > From: dev On Behalf Of Jie Wang
> > Sent: Tuesday, October 12, 2021 1:25 PM
> > Subject: [dpdk-dev] [PATCH v2 2/3] app/testpmd: support PPPoL2TPv2oUDP
> > RSS Hash
> >
> > Add support for test-pmd to parse protocol pattern L2TPv2 and PPP.
> >
> > Signed-off-by: Wenjun Wu
> > Signed-off-by: Jie Wang
> > ---
> > app/test-pmd/cmdline_flow.c | 34 ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> > index
> > bb22294dd3..3c9bcabd97 100644
> > --- a/app/test-pmd/cmdline_flow.c
> > +++ b/app/test-pmd/cmdline_flow.c
> > @@ -299,6 +299,8 @@ enum index {
> > ITEM_GENEVE_OPT_TYPE,
> > ITEM_GENEVE_OPT_LENGTH,
> > ITEM_GENEVE_OPT_DATA,
> > + ITEM_PPP,
> > + ITEM_L2TPV2,
> > ITEM_INTEGRITY,
> > ITEM_INTEGRITY_LEVEL,
> > ITEM_INTEGRITY_VALUE,
> > @@ -997,6 +999,8 @@ static const enum index next_item[] = {
> > ITEM_AH,
> > ITEM_PFCP,
> > ITEM_ECPRI,
> > + ITEM_PPP,
> > + ITEM_L2TPV2,
>
> Why in the middle?
>
Ok, I will update it.
> > ITEM_GENEVE_OPT,
> > ITEM_INTEGRITY,
> > ITEM_CONNTRACK,
> > @@ -1368,6 +1372,16 @@ static const enum index item_integrity_lv[] = {
> > ZERO,
> > };
> >
> > +static const enum index item_ppp[] = {
> > + ITEM_NEXT,
> > + ZERO,
> > +};
> > +
> > +static const enum index item_l2tpv2[] = {
> > + ITEM_NEXT,
> > + ZERO,
> > +};
> > +
> > static const enum index next_action[] = {
> > ACTION_END,
> > ACTION_VOID,
> > @@ -3579,6 +3593,20 @@ static const struct token token_list[] = {
> > (sizeof(struct rte_flow_item_geneve_opt),
> > ITEM_GENEVE_OPT_DATA_SIZE)),
> > },
> > + [ITEM_PPP] = {
> > + .name = "ppp",
> > + .help = "match ppp header",
> > + .priv = PRIV_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
> > + .next = NEXT(item_ppp),
> > + .call = parse_vc,
> > + },
> > + [ITEM_L2TPV2] = {
> > + .name = "l2tpv2",
> > + .help = "match l2tpv2 header",
> > + .priv = PRIV_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
> > + .next = NEXT(item_l2tpv2),
> > + .call = parse_vc,
> > + },
> > [ITEM_INTEGRITY] = {
> > .name = "integrity",
> > .help = "match packet integrity",
> > @@ -8343,6 +8371,12 @@ flow_item_default_mask(const struct
> rte_flow_item *item)
> > case RTE_FLOW_ITEM_TYPE_PFCP:
> > mask = &rte_flow_item_pfcp_mask;
> > break;
> > + case RTE_FLOW_ITEM_TYPE_L2TPV2:
> > + mask = &rte_flow_item_l2tpv2_mask;
> > + break;
> > + case RTE_FLOW_ITEM_TYPE_PPP:
> > + mask = &rte_flow_item_ppp_mask;
> > + break;
> > default:
> > break;
> > }
> > --
> > 2.25.1
>
> Maybe I'm missing something but I don't see that you added the ability to
> match
> on any of the header fields value.
> You also didn't update the code of encap (from my understanding this is a
> tunnel
> header)
>
> Best,
> Ori
Hi Ori,
This feature is only support for iavf enable PPPoL2TPv2oUDP rss. So it doesn't
need to add the ability to match on any of the header fields value and the code
of encap.
I'm not sure if it is necessary to add these.
Re: [dpdk-dev] [PATCH v6 1/3] eal/linux: make hugetlbfs analysis reusable
Hello,
On Mon, Oct 11, 2021 at 10:57 AM Dmitry Kozlyuk wrote:
>
> get_hugepage_dir() searched for a hugetlbfs mount with a given page size
> using handcraft parsing of /proc/mounts and mixing traversal logic with
> selecting the needed entry. Separate code to enumerate hugetlbfs mounts
> to eal_hugepage_mount_walk() taking a callback that can inspect already
> parsed entries. Use mntent(3) API for parsing. This allows to reuse
> enumeration logic in subsequent patches.
>
> Signed-off-by: Dmitry Kozlyuk
> Reviewed-by: Viacheslav Ovsiienko
> Reviewed-by: John Levon
As you probably noticed, I merged John patch.
Could you rebase this series on the main branch please?
Two minor comments below:
> ---
> lib/eal/linux/eal_hugepage_info.c | 153 +++---
> lib/eal/linux/eal_hugepage_info.h | 39
> 2 files changed, 135 insertions(+), 57 deletions(-)
> create mode 100644 lib/eal/linux/eal_hugepage_info.h
>
> diff --git a/lib/eal/linux/eal_hugepage_info.c
> b/lib/eal/linux/eal_hugepage_info.c
> index d97792cade..193282e779 100644
> --- a/lib/eal/linux/eal_hugepage_info.c
> +++ b/lib/eal/linux/eal_hugepage_info.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -34,6 +35,7 @@
> #include "eal_private.h"
> #include "eal_internal_cfg.h"
> #include "eal_hugepages.h"
> +#include "eal_hugepage_info.h"
> #include "eal_filesystem.h"
>
> static const char sys_dir_path[] = "/sys/kernel/mm/hugepages";
> @@ -195,73 +197,110 @@ get_default_hp_size(void)
> return size;
> }
>
> -static int
> -get_hugepage_dir(uint64_t hugepage_sz, char *hugedir, int len)
> +int
> +eal_hugepage_mount_walk(eal_hugepage_mount_walk_cb *cb, void *cb_arg)
> {
> - enum proc_mount_fieldnames {
> - DEVICE = 0,
> - MOUNTPT,
> - FSTYPE,
> - OPTIONS,
> - _FIELDNAME_MAX
> - };
> - static uint64_t default_size = 0;
> - const char proc_mounts[] = "/proc/mounts";
> - const char hugetlbfs_str[] = "hugetlbfs";
> - const size_t htlbfs_str_len = sizeof(hugetlbfs_str) - 1;
> - const char pagesize_opt[] = "pagesize=";
> - const size_t pagesize_opt_len = sizeof(pagesize_opt) - 1;
> - const char split_tok = ' ';
> - char *splitstr[_FIELDNAME_MAX];
> - char buf[BUFSIZ];
> - int retval = -1;
> - const struct internal_config *internal_conf =
> - eal_get_internal_configuration();
> -
> - FILE *fd = fopen(proc_mounts, "r");
> - if (fd == NULL)
> - rte_panic("Cannot open %s\n", proc_mounts);
> + static const char PATH[] = "/proc/mounts";
> + static const char OPTION[] = "pagesize";
Nit: please avoid PATH and OPTION as variable names.
All-uppercase words are usually for macros/defines in dpdk.
Plus, in PATH case, this is a well known shell variable.
> +
> + static uint64_t default_size;
> +
> + FILE *f = NULL;
> + struct mntent mntent;
> + char strings[PATH_MAX];
> + char *hugepage_sz_str;
> + uint64_t hugepage_sz;
> + bool stopped = false;
> + int ret = -1;
> +
> + f = setmntent(PATH, "r");
> + if (f == NULL) {
> + RTE_LOG(ERR, EAL, "%s(): setmntent(%s): %s\n",
> + __func__, PATH, strerror(errno));
> + goto exit;
We are in a rather generic helper function.
Error messages should be logged by callers of this helper, because the
caller knows better what the impact of failing to list mountpoints is.
In the helper itself, this log should probably be info or debug level.
If you think this error-level log should be kept in the helper, can
you make it a bit higher level so that users understand what is wrong
and what actions should be done to fix the situation?
> + }
>
> if (default_size == 0)
> default_size = get_default_hp_size();
>
> - while (fgets(buf, sizeof(buf), fd)){
> - if (rte_strsplit(buf, sizeof(buf), splitstr, _FIELDNAME_MAX,
> - split_tok) != _FIELDNAME_MAX) {
> - RTE_LOG(ERR, EAL, "Error parsing %s\n", proc_mounts);
> - break; /* return NULL */
> + ret = 0;
> + while (getmntent_r(f, &mntent, strings, sizeof(strings)) != NULL) {
> + if (strcmp(mntent.mnt_type, "hugetlbfs") != 0)
> + continue;
> +
> + hugepage_sz_str = hasmntopt(&mntent, OPTION);
> + if (hugepage_sz_str != NULL) {
> + hugepage_sz_str += strlen(OPTION) + 1; /* +1 for '='
> */
> + hugepage_sz = rte_str_to_size(hugepage_sz_str);
> + if (hugepage_sz == 0) {
> + RTE_LOG(DEBUG, EAL, "Cannot parse hugepage
> size from '%s' for %s\n",
> +
Re: [dpdk-dev] [PATCH] examples/l2fwd: add promiscuous mode selection through command line option
On Wed, Oct 13, 2021 at 12:23:03PM +0500, Sarosh Arif wrote: > The default behaviour of l2fwd is to exit if we are unable to turn > promiscuous mode on. On some aws instances turning promiscuous mode > on is not permitted. In such cases there should be a way to run the > application without promiscuous mode. > > This patch allows user to turn promiscuous mode on via command line > parameter. l3fwd has a similar option available. > > Signed-off-by: Sarosh Arif > --- This is a behaviour change, but since this is sample application, I think it's acceptable, and agree that the change is needed. Acked-by: Bruce Richardson
Re: [dpdk-dev] [PATCH 2/5] ethdev: add capability to keep shared objects on restart
This thread continues discussions on previous versions to keep everything in the thread with final patches: [1]: http://inbox.dpdk.org/dev/d5673b58-5aa6-ca35-5b60-d938e56cf...@oktetlabs.ru/ [2]: http://inbox.dpdk.org/dev/dm8pr12mb5400997ccec9169ac5ae0c89d6...@dm8pr12mb5400.namprd12.prod.outlook.com/ Please see below. > -Original Message- > From: Dmitry Kozlyuk > Sent: 5 октября 2021 г. 3:52 > To: dev@dpdk.org > Cc: Dmitry Kozlyuk ; Ori Kam ; NBU- > Contact-Thomas Monjalon ; Ferruh Yigit > ; Andrew Rybchenko > Subject: [PATCH 2/5] ethdev: add capability to keep shared objects on > restart > > From: Dmitry Kozlyuk > > rte_flow_action_handle_create() did not mention what happens with an > indirect action when a device is stopped, possibly reconfigured, and > started again. It is natural for some indirect actions to be persistent, > like counters and meters; keeping others just saves application time and > complexity. However, not all PMDs can support it. > It is proposed to add a device capability to indicate if indirect actions > are kept across the above sequence or implicitly destroyed. > > In the future, indirect actions may not be the only type of objects shared > between flow rules. The capability bit intends to cover all possible types > of such objects, hence its name. > > It may happen that in the future a PMD acquires support for a type of > shared objects that it cannot keep across a restart. It is undesirable to > stop advertising the capability so that applications that don't use > objects of the problematic type can still take advantage of it. > This is why PMDs are allowed to keep only a subset of shared objects > provided that the vendor mandatorily documents it. > > If the device is being reconfigured in a way that is incompatible with an > existing shared objects, PMD is required to report an error. > This is mandatory, because flow API does not supply users with > capabilities, so this is the only way for a user to learn that > configuration is invalid. For example, if queue count changes and RSS > indirect action specifies queues that are going away, the user must update > the action before removing the queues or remove the action and all flow > rules that were using it. > > Signed-off-by: Dmitry Kozlyuk > --- > [...] Current pain point is that capability bits may be insufficient and a programmatic way is desired to check which types of objects can be kept across restart, instead of documenting the limitations. I support one of previous Ori's suggestions and want to clarify it [1]: Ori: "Another way is to assume that if the action was created before port start it will be kept after port stop." Andrew: "It does not sound like a solution. May be I simply don't know target usecase." What Ori suggests (offline discussion summary): Suppose an application wants to check whether a shared object (indirect action) or a flow rule of a particular kind. It calls rte_flow_action_handle_create() or rte_flow_create() before rte_eth_dev_start(). If it succeeds, 1) it means objects of this type can be kept across restart, 2) it's a normal object created that will work after the port is started. This is logical, because if the PMD can keep some kind of objects when the port is stopped, it is likely to be able to create them when the port is not started. It is subject to discussion if "object kind" means only "type" or "type + transfer bit" combination; for mlx5 PMD it doesn't matter. One minor drawback is that applications can only do the test when the port is stopped, but it seems likely that the test really needs to be done at startup anyway. If this is acceptable: 1. Capability bits are not needed anymore. 2. ethdev patches can be accepted in RC1, present behavior is undefined anyway. 3. PMD patches will need update that can be done by RC2.
Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to keep indirect actions on restart
Please let's continue in the thread for the latest version of the patches: http://inbox.dpdk.org/dev/ch0pr12mb5091792a77cbd1528db7a005b9...@ch0pr12mb5091.namprd12.prod.outlook.com/ Please see my comments there. > -Original Message- > From: Andrew Rybchenko > Sent: 12 октября 2021 г. 13:41 > To: Ori Kam ; Dmitry Kozlyuk ; Ajit > Khaparde > Cc: dpdk-dev ; Matan Azrad ; NBU- > Contact-Thomas Monjalon ; Ferruh Yigit > > Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to keep > indirect > actions on restart > > External email: Use caution opening links or attachments > > > On 10/12/21 1:26 PM, Ori Kam wrote: > > Hi > > > >> -Original Message- > >> From: Andrew Rybchenko > >> Sent: Tuesday, October 12, 2021 12:15 PM > >> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to > >> keep indirect actions on restart > >> > >> On 10/11/21 6:53 PM, Ori Kam wrote: > >>> Hi Andrew and Ajit, > >>> > -Original Message- > From: Andrew Rybchenko > Sent: Monday, October 11, 2021 4:58 PM > Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to > keep indirect actions on restart > > On 10/7/21 11:16 AM, Dmitry Kozlyuk wrote: > >> -Original Message- > >> From: Ajit Khaparde > >> Sent: 6 октября 2021 г. 20:13 > >> To: Dmitry Kozlyuk > >> Cc: dpdk-dev ; Matan Azrad ; Ori > >> Kam ; NBU-Contact-Thomas Monjalon > >> ; Ferruh Yigit ; > >> Andrew Rybchenko > >> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to > >> keep indirect actions on restart > >> > >> On Wed, Sep 1, 2021 at 1:55 AM Dmitry Kozlyuk > wrote: > >>> > >>> rte_flow_action_handle_create() did not mention what happens > >>> with an indirect action when a device is stopped, possibly > >>> reconfigured, and started again. It is natural for some indirect > >>> actions to be persistent, like counters and meters; keeping > >>> others just saves application time and complexity. However, not all > PMDs can support it. > >>> It is proposed to add a device capability to indicate if > >>> indirect actions are kept across the above sequence or implicitly > destroyed. > >>> > >>> It may happen that in the future a PMD acquires support for a > >>> type of indirect actions that it cannot keep across a restart. > >>> It is undesirable to stop advertising the capability so that > >>> applications that don't use actions of the problematic type can still > >>> take > advantage of it. > >>> This is why PMDs are allowed to keep only a subset of indirect > >>> actions provided that the vendor mandatorily documents it. > >> Sorry - I am seeing this late. > >> This could become confusing. > >> May be it is better for the PMDs to specify which actions are > >> persistent. > >> How about adding a bit for the possible actions of interest. > >> And then PMDs can set bits for actions which can be persistent > >> across stop, start and reconfigurations? > > > > This approach was considered, but there is a risk of quickly > > running out of capability bits. Each action > would consume one bit plus as many bits as there are special > conditions for it in all the PMDs, because conditions are likely to > be PMD-specific. And the application will anyway need to consider > specific conditions to know which bit to test, so the meaning of > the bits will be PMD-specific. On the > >> other hand, PMDs are not expected to exercise this loophole unless > absolutely needed. > > > >>> Right those bits should be considered as master bits and are not per > >>> actions. > >>> If there is specific case for a PMD it should solve it by documation or > >>> other > means. > >> > >> Documentation does not solve the problem since it can't be automated. > >> So, it just help to solve case-by- case. > > > > I agree that documentation can't be automated, I think this is just > > like other edge cases that can't be checked for example you can > > reconfigure the device after start except the queue number or queue size > > (just > an example) The metrix of actions/items/pmds I don't think we will ever be > able > to have an easy way to check capabilities. > > > > Maybe we can say that if PMD reports that it supports keeping the > > actions, and it can't support just one of the actions it can fail or issue > > a special > error code when calling stop. To let the application know that something was > incorrect. > > In this case application can create a sample of the action it requires > > and then call the stop. If it fails it can try again until he gets no > > error, and only > then start. What do you think? > > It all sounds complicated. Do we really need it? > > > Another way is to assume that if the action was created before port start > > it will > be kept after port stop. > > It does not sound like
Re: [dpdk-dev] [PATCH] mbuf: enforce no option for dynamic fields and flags
On 12/10/2021 20:39, David Marchand wrote:
> As stated in the API, dynamic field and flags should be created with no
> additional flag (simply in the API for future changes).
>
> Fix the dynamic flag register helper which was not enforcing it and add
> unit tests.
>
> Fixes: 4958ca3a443a ("mbuf: support dynamic fields and flags")
>
> Signed-off-by: David Marchand
> ---
> app/test/test_mbuf.c| 18 ++
> lib/mbuf/rte_mbuf_dyn.c | 4
> 2 files changed, 22 insertions(+)
Acked-by: Ray Kinsella
Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
On 13/10/2021 08:04, Anoob Joseph wrote: > Hi Akhil, Ray, Thomas, > > Please see inline. > > Thanks, > Anoob > >> -Original Message- >> From: Thomas Monjalon >> Sent: Wednesday, October 13, 2021 12:32 PM >> To: Akhil Goyal ; dev@dpdk.org; Kinsella, Ray >> ; Anoob Joseph >> Cc: david.march...@redhat.com; hemant.agra...@nxp.com; >> pablo.de.lara.gua...@intel.com; fiona.tr...@intel.com; >> declan.dohe...@intel.com; ma...@nvidia.com; g.si...@nxp.com; >> roy.fan.zh...@intel.com; jianjay.z...@huawei.com; asoma...@amd.com; >> ruifeng.w...@arm.com; konstantin.anan...@intel.com; >> radu.nico...@intel.com; ajit.khapa...@broadcom.com; Nagadheeraj >> Rottela ; Ankur Dwivedi >> ; ciara.po...@intel.com; Stephen Hemminger >> ; Yigit, Ferruh ; >> bruce.richard...@intel.com >> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove >> LIST_END enumerators >> >> 13/10/2021 07:36, Anoob Joseph: >>> From: Thomas Monjalon 12/10/2021 16:47, Kinsella, Ray: > On 12/10/2021 15:18, Anoob Joseph wrote: >> From: Thomas Monjalon >>> 12/10/2021 15:38, Anoob Joseph: From: Thomas Monjalon > 12/10/2021 13:34, Anoob Joseph: >> From: Kinsella, Ray >>> On 12/10/2021 11:50, Anoob Joseph wrote: From: Akhil Goyal >> On 08/10/2021 21:45, Akhil Goyal wrote: >>> Remove *_LIST_END enumerators from asymmetric >> crypto lib to >>> avoid ABI breakage for every new addition in enums. >>> >>> Signed-off-by: Akhil Goyal >>> --- >>> - } else if (xform->xform_type >= >> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END >>> + } else if (xform->xform_type > > RTE_CRYPTO_ASYM_XFORM_ECPM > [...] >> >> So I am not sure that this is an improvement. > > Indeed, it is not an improvement. > >> The cryptodev issue we had, was that _LIST_END was being >> used to size arrays. >> And that broke when new algorithms got added. Is that an >> issue, in this >>> case? > > Yes we did this same exercise for symmetric crypto enums earlier. > Asym enums were left as it was experimental at that point. > They are still experimental, but thought of making this > uniform throughout DPDK enums. > >> >> I am not sure that swapping out _LIST_END, and then >> littering the code with RTE_CRYPTO_ASYM_XFORM_ECPM >> and >> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an > improvement > here. >> >> My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is >> not better or worse, than >>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE? >> >> Interested to hear other thoughts. > > I don’t have any better solution for avoiding ABI issues for >> now. > The change is for avoiding ABI breakage. But we can drop > this patch For now as asym is still experimental. [Anoob] Having LIST_END would preclude new additions to asymmetric > algos? >>> If yes, then I would suggest we address it now. >>> >>> Not at all - but it can be problematic, if two versions of >>> DPDK disagree with the value of LIST_END. >>> Looking at the "problematic changes", we only have 2-3 application & PMD changes. For unit test application, we could may be do something like, >>> >>> The essental functionality not that different, I am just >>> not sure that the verbosity below is helping. >>> What you are really trying to guard against is people using >>> LIST_END to size arrays. >> >> [Anoob] Our problem is application using LIST_END (which >> comes from library) > to determine the number of iterations for the loop. My > suggestion is to modify the UT such that, we could use > RTE_DIM(types) (which comes from application) to determine > iterations of loop. This would solve the >>> problem, right? > > The problem is not the application. > Are you asking the app to define DPDK types? [Anoob] I didn't understand how you concluded that. >>> >>> Because you define a specific array in the test app. >>> The app is supposed to test "n" asymmetric features supported by DPDK. >>> Currently, it does that by looping from 0 to LIST_END which >>> happens to give you the first n features. Now, if we add any >>> new asymmetric feature, LIST_END value would change. Isn't that >>> the very reason why we removed LIST_END from symmetric library >> and appli
Re: [dpdk-dev] [PATCH v3 04/10] common/sfc_efx/base: add RECIRC ID match in action rules API
On 13/10/2021 01:24, Ivan Malov wrote: > Currently, there is an API for setting recirculation ID in > outer rules. Add an API to let action rules match on it. > > Signed-off-by: Ivan Malov > Reviewed-by: Andrew Rybchenko > --- > drivers/common/sfc_efx/base/efx.h | 13 ++ > drivers/common/sfc_efx/base/efx_mae.c | 36 --- > drivers/common/sfc_efx/version.map| 1 + > 3 files changed, 46 insertions(+), 4 deletions(-) > Acked-by: Ray Kinsella
Re: [dpdk-dev] [PATCH v12 00/12] Packet capture framework update
> -Original Message- > From: Thomas Monjalon > > Thought they were, look like Reshma got missed. > > > > No worries about doing in 22.02 since there is no API/ABI breakage in > > the patchset. No pre-release note needed either. > > We can still merge it for 21.11 if Reshma is OK with the v12. > FYI, I have reviewed and acked the below pdump library patch. [v12,06/12] pdump: support pcapng and filtering There are some other patches , mainly new library librte_pcapng which needs a review and an Ack, can someone join to review and provide an Ack? I will also take a look. Thanks, Reshma
Re: [dpdk-dev] [PATCH] memzone: enforce valid flags when reserving
On 10/12/21 11:14 PM, Stephen Hemminger wrote: > On Tue, 12 Oct 2021 21:39:26 +0200 > David Marchand wrote: > >> If we do not enforce valid flags are passed by an application, this >> application might face issues in the future when we add more flags. >> >> Signed-off-by: David Marchand > > Acked-by: Stephen Hemminger > Acked-by: Andrew Rybchenko
Re: [dpdk-dev] [PATCH v12 2/2] app/testpmd: fix testpmd doesn't show RSS hash offload
On 10/13/2021 3:42 AM, Wang, Jie1X wrote:
-Original Message-
From: Yigit, Ferruh
Sent: Tuesday, October 12, 2021 10:38 PM
To: Wang, Jie1X ; dev@dpdk.org
Cc: tho...@monjalon.net; andrew.rybche...@oktetlabs.ru; Li, Xiaoyun
; Yang, SteveX
Subject: Re: [PATCH v12 2/2] app/testpmd: fix testpmd doesn't show RSS hash
offload
On 10/12/2021 3:54 AM, Jie Wang wrote:
The driver may change offloads info into dev->data->dev_conf in
dev_configure which may cause port->dev_conf and port->rx_conf contain
outdated values.
This patch updates the offloads info if it changes to fix this issue.
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Signed-off-by: Jie Wang
Hi Jie,
ci/intel-Testing is still reporting some errors [1] with this patch, did you
able to
investigate the reason of it?
This error seems not seen in other patches, so that shouldn't be an
infrastructure
problem.
[1]
http://mails.dpdk.org/archives/test-report/2021-October/226766.html
Hi Ferruh,
When the dpdk runs the test_pf_tx_rx_queue test case, the port will be
configured with rxq/txq to 1. This will cause the test to fail.
In rte_eth_dev_configure, if rxq/txq is 1, dev_conf->rxmode.mq_mode is ETH_MQ_RX_NONE, and
dev_conf->rxmode.offloads contains the DEV_RX_OFFLOAD_RSS_HASH value by default, which
causes the program to report an error " Ethdev port_id=0 config invalid Rx mq_mode without
RSS but RSS_HASH offload is requested".
When the port needs to configure txq/txq to 1, first clear the RSS_HASH
configuration of dev_conf->rxmode.offloads.
And I have talked about this error with the tester a few days ago, and they
will modify the test case. They will add a command (port config port_id
rx_offload rss_hash off) before configuring txq/rxq to 1.
I see, but shouldn't this fail for all patches, why it is only failing
for this set?
Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
On 12/10/2021 22:52, Thomas Monjalon wrote: > 12/10/2021 22:34, Dumitrescu, Cristian: >> From: Thomas Monjalon >>> 01/09/2021 14:20, Jasvinder Singh: These APIs were introduced in 18.05, therefore removing experimental tag to promote them to stable state. Signed-off-by: Jasvinder Singh --- lib/pipeline/rte_port_in_action.h | 10 -- lib/pipeline/rte_table_action.h | 18 -- lib/pipeline/version.map | 16 ++-- 3 files changed, 6 insertions(+), 38 deletions(-) >>> >>> Cristian, please can you check whether you intend to keep these functions in >>> future? >>> If they are candidate to be removed, there is no point to promote them. >> >> Hi Thomas, >> >> Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves. >> >> But removing them requires updating the drivers/net/softnic code to use the >> new API, which is not going to be completed in time for release 21.11. >> >> So given this lag, it might be better to simply promote these functions to >> stable API now, as Ray suggests, instead of continuing to keep them >> experimental; then, once these functions are no longer used, then we can >> remove them, most likely in 22.11. >> >> So I will ack these patches, but I am willing to reconsider if you feel >> strongly against this approach. > > I think we should not promote API that we know will disappear soon. > The stable status means something for the users. > Ray, what is your opinion? > Well - I agree with Cristian (he and I discuss this a few weeks ago). My position is if you are going to maintain an API, that means giving a few guarantees. The API's have been experimental for 3 years ... at what point do they mature? However, I agree there is two ways to look at this thing, I try to be pragmatic. Maturing of any ABI/API is a conversation between a maintainer and the contributor. If they strongly feel, it is a pointless exercise - I won't argue. Ray K
Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
On 12/10/2021 21:34, Dumitrescu, Cristian wrote: > > >> -Original Message- >> From: Singh, Jasvinder >> Sent: Wednesday, September 1, 2021 1:20 PM >> To: dev@dpdk.org >> Cc: Dumitrescu, Cristian ; m...@ashroe.eu; >> Zhang, Roy Fan >> Subject: [PATCH] pipeline: remove experimental tag from API >> >> These APIs were introduced in 18.05, therefore removing >> experimental tag to promote them to stable state. >> >> Signed-off-by: Jasvinder Singh >> --- >> lib/pipeline/rte_port_in_action.h | 10 -- >> lib/pipeline/rte_table_action.h | 18 -- >> lib/pipeline/version.map | 16 ++-- >> 3 files changed, 6 insertions(+), 38 deletions(-) >> >> diff --git a/lib/pipeline/rte_port_in_action.h >> b/lib/pipeline/rte_port_in_action.h >> index d6b063cf58..de611cbfab 100644 >> --- a/lib/pipeline/rte_port_in_action.h >> +++ b/lib/pipeline/rte_port_in_action.h >> @@ -42,8 +42,6 @@ >> *used by the input port action handler based on given action >> parameters. >> *API functions: rte_port_in_action_apply(). >> * >> - * @warning >> - * @b EXPERIMENTAL: this API may change without prior notice >> */ >> >> #ifdef __cplusplus >> @@ -172,7 +170,6 @@ struct rte_port_in_action_profile; >> * @return >> * Input port action profile handle on success, NULL otherwise. >> */ >> -__rte_experimental >> struct rte_port_in_action_profile * >> rte_port_in_action_profile_create(uint32_t socket_id); >> >> @@ -184,7 +181,6 @@ rte_port_in_action_profile_create(uint32_t >> socket_id); >> * @return >> * Zero on success, non-zero error code otherwise. >> */ >> -__rte_experimental >> int >> rte_port_in_action_profile_free(struct rte_port_in_action_profile *profile); >> >> @@ -203,7 +199,6 @@ rte_port_in_action_profile_free(struct >> rte_port_in_action_profile *profile); >> * @return >> * Zero on success, non-zero error code otherwise. >> */ >> -__rte_experimental >> int >> rte_port_in_action_profile_action_register( >> struct rte_port_in_action_profile *profile, >> @@ -226,7 +221,6 @@ rte_port_in_action_profile_action_register( >> * >> * @see rte_port_in_action_create() >> */ >> -__rte_experimental >> int >> rte_port_in_action_profile_freeze(struct rte_port_in_action_profile >> *profile); >> >> @@ -249,7 +243,6 @@ struct rte_port_in_action; >> * @return >> * Handle to input port action object on success, NULL on error. >> */ >> -__rte_experimental >> struct rte_port_in_action * >> rte_port_in_action_create(struct rte_port_in_action_profile *profile, >> uint32_t socket_id); >> @@ -262,7 +255,6 @@ rte_port_in_action_create(struct >> rte_port_in_action_profile *profile, >> * @return >> * Zero on success, non-zero error code otherwise. >> */ >> -__rte_experimental >> int >> rte_port_in_action_free(struct rte_port_in_action *action); >> >> @@ -276,7 +268,6 @@ rte_port_in_action_free(struct rte_port_in_action >> *action); >> * @return >> * Zero on success, non-zero error code otherwise. >> */ >> -__rte_experimental >> int >> rte_port_in_action_params_get(struct rte_port_in_action *action, >> struct rte_pipeline_port_in_params *params); >> @@ -296,7 +287,6 @@ rte_port_in_action_params_get(struct >> rte_port_in_action *action, >> * @return >> * Zero on success, non-zero error code otherwise. >> */ >> -__rte_experimental >> int >> rte_port_in_action_apply(struct rte_port_in_action *action, >> enum rte_port_in_action_type type, >> diff --git a/lib/pipeline/rte_table_action.h >> b/lib/pipeline/rte_table_action.h >> index 82bc9d9ac9..aac6b8ce8d 100644 >> --- a/lib/pipeline/rte_table_action.h >> +++ b/lib/pipeline/rte_table_action.h >> @@ -48,8 +48,6 @@ >> * - Use the table action object to read action data (e.g. stats counters) >> for >> *any given rule. API functions: rte_table_action_XYZ_read(). >> * >> - * @warning >> - * @b EXPERIMENTAL: this API may change without prior notice >> */ >> >> #ifdef __cplusplus >> @@ -823,7 +821,6 @@ struct rte_table_action_profile; >> * @return >> * Table action profile handle on success, NULL otherwise. >> */ >> -__rte_experimental >> struct rte_table_action_profile * >> rte_table_action_profile_create(struct rte_table_action_common_config >> *common); >> >> @@ -835,7 +832,6 @@ rte_table_action_profile_create(struct >> rte_table_action_common_config *common); >> * @return >> * Zero on success, non-zero error code otherwise. >> */ >> -__rte_experimental >> int >> rte_table_action_profile_free(struct rte_table_action_profile *profile); >> >> @@ -854,7 +850,6 @@ rte_table_action_profile_free(struct >> rte_table_action_profile *profile); >> * @return >> * Zero on success, non-zero error code otherwise. >> */ >> -__rte_experimental >> int >> rte_table_action_profile_action_register(struct rte_table_action_profile >> *profile, >> enum rte_table_action_type type, >> @@ -875,7 +870,6 @@ rte_table_action_profile_
Re: [dpdk-dev] [PATCH] net/softnic: remove experimental table from API
On 01/09/2021 13:20, Jasvinder Singh wrote: > This API was introduced in 18.08, therefore removing > experimental tag to promote it to stable state. > > Signed-off-by: Jasvinder Singh > --- > drivers/net/softnic/rte_eth_softnic.h | 1 - > drivers/net/softnic/version.map | 7 +-- > 2 files changed, 1 insertion(+), 7 deletions(-) > Acked-by: Ray Kinsella
Re: [dpdk-dev] [PATCH] sched: remove experimental tag from the API
On 01/09/2021 13:19, Jasvinder Singh wrote: > This API was introduced in 18.05, therefore removing > experimental tag to promote it to stable state > > Signed-off-by: Jasvinder Singh > --- > lib/sched/rte_sched.h | 4 > lib/sched/version.map | 2 +- > 2 files changed, 1 insertion(+), 5 deletions(-) > Acked-by: Ray Kinsella
[dpdk-dev] [PATCH] mempool: fix name size in mempool structure
Use correct define as a name array size.
The change breaks ABI and therefore cannot be backported to
stable branches.
Fixes: 38c9817ee1d8 ("mempool: adjust name size in related data types")
Signed-off-by: Andrew Rybchenko
---
lib/mempool/rte_mempool.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
index f57ecbd6fc..04b14d7ae9 100644
--- a/lib/mempool/rte_mempool.h
+++ b/lib/mempool/rte_mempool.h
@@ -209,12 +209,7 @@ struct rte_mempool_info {
* The RTE mempool structure.
*/
struct rte_mempool {
- /*
-* Note: this field kept the RTE_MEMZONE_NAMESIZE size due to ABI
-* compatibility requirements, it could be changed to
-* RTE_MEMPOOL_NAMESIZE next time the ABI changes
-*/
- char name[RTE_MEMZONE_NAMESIZE]; /**< Name of mempool. */
+ char name[RTE_MEMPOOL_NAMESIZE]; /**< Name of mempool. */
RTE_STD_C11
union {
void *pool_data; /**< Ring or pool to store objects. */
--
2.30.2
Re: [dpdk-dev] [PATCH v5] net: introduce IPv4 ihl and version fields
On 12/10/2021 13:29, Gregory Etelson wrote: > RTE IPv4 header definition combines the `version' and `ihl' fields > into a single structure member. > This patch introduces dedicated structure members for both `version' > and `ihl' IPv4 fields. Separated header fields definitions allow to > create simplified code to match on the IHL value in a flow rule. > The original `version_ihl' structure member is kept for backward > compatibility. > The patch implements one of 2 announced changes to the > IPv4 header. > IPv4 header encodes fragment information into 16 bits field. > 3 bits hold flags and remaining 13 bits are for fragment offset. > 13 bits bit-field cannot be defined both for big and little endian > systems. > > Signed-off-by: Gregory Etelson > > Acked-by: Olivier Matz > Acked-by: Ray Kinsella
Re: [dpdk-dev] [PATCH 3/3] ethdev: add async queue-based flow rules operations
On Tue, Oct 5, 2021 at 9:49 PM Alexander Kozyrev wrote:
>
> A new, faster, queue-based flow rules management mechanism is needed for
> applications offloading rules inside the datapath. This asynchronous
> and lockless mechanism frees the CPU for further packet processing and
> reduces the performance impact of the flow rules creation/destruction
> on the datapath. Note that queues are not thread-safe and queue-based
> operations can be safely invoked without any locks from a single thread.
>
> The rte_flow_q_flow_create() function enqueues a flow creation to the
> requested queue. It benefits from already configured resources and sets
> unique values on top of item and action templates. A flow rule is enqueued
> on the specified flow queue and offloaded asynchronously to the hardware.
> The function returns immediately to spare CPU for further packet
> processing. The application must invoke the rte_flow_q_dequeue() function
> to complete the flow rule operation offloading, to clear the queue, and to
> receive the operation status. The rte_flow_q_flow_destroy() function
> enqueues a flow destruction to the requested queue.
>
> Signed-off-by: Alexander Kozyrev
> Suggested-by: Ori Kam
> ---
> lib/ethdev/rte_flow.h | 288 ++
> 1 file changed, 288 insertions(+)
>
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index ba3204b17e..8cdffd8d2e 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -4298,6 +4298,13 @@ struct rte_flow_port_attr {
> * Version of the struct layout, should be 0.
> */
> uint32_t version;
> + /**
> +* Number of flow queues to be configured.
> +* Flow queues are used for asyncronous flow rule
> creation/destruction.
> +* The order of operations is not guaranteed inside a queue.
> +* Flow queues are not thread-safe.
> +*/
> + uint16_t nb_queues;
Will it matter if PMD can create a smaller set of queues? Or may be just one?
Should the application set this based on get_infos_get() or some other
mechanism?
Re: [dpdk-dev] [PATCH] memzone: enforce valid flags when reserving
On 12/10/2021 20:39, David Marchand wrote: > If we do not enforce valid flags are passed by an application, this > application might face issues in the future when we add more flags. > > Signed-off-by: David Marchand > --- > app/test/test_memzone.c | 24 > lib/eal/common/eal_common_memzone.c | 17 + > 2 files changed, 41 insertions(+) Acked-by: Ray Kinsella
Re: [dpdk-dev] [PATCH v2] ip_frag: fix fragmenting IPv4 fragment
Hi Kevin,
AFAIK, no other action from your side is needed at the moment.
Now it is up to other reviewers (if any) to have a look,
and then DPDK maintainers to bring your patch in.
If they will have more comments/questions about the patch -
they will email you.
Meanwhile, as I said before, it would be really good to add a new
test-case to cover that case. It could be a new separate patch on top
of current one.
Konstantin
From: 蔡慧超
Sent: Wednesday, October 13, 2021 7:53 AM
To: Ananyev, Konstantin
Cc: dev@dpdk.org; sta...@dpdk.org
Subject: Re:RE: [PATCH v2] ip_frag: fix fragmenting IPv4 fragment
Hi,Konstantin
I'm glad to receive your ack！
Follow the documentation 《Contributing Code to DPDK》：
1.Update Patchwork to mark your previous patches as “Superseded”.
--Who is responsible for this update, I just tried, prompt no permission update(
You don't have permissions to edit patch 'ip_frag: modify the fragment offset
and mf').
2.Note: When acking patches please remove as much of the text of the patch
email as possible.
It is generally best to delete everything after the Signed-off-by: line.
--Does this require me to send another patch email?And the content is like this:
Current implementation of rte_ipv4_fragment_packet() doesn’t take
into account offset and flag values of the given packet, but blindly
assumes they are always zero (original packet is not fragmented).
According to RFC791, fragment and flag values for new fragment
should take into account values provided in the original IPv4 packet.
Fixes: 4c38e5532a07 ("ip_frag: refactor IPv4 fragmentation into a proper
library")
Cc: sta...@dpdk.org
Signed-off-by: huichao cai mailto:chcch...@163.com>>
Acked-by: Konstantin Ananyev
mailto:konstantin.anan...@intel.com>>
---
v2:(delete)
* Reword commit message.(delete)
lib/ip_frag/rte_ipv4_fragmentation.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
Best regards.
Kevin
Re: [dpdk-dev] [PATCH v6 1/3] eal/linux: make hugetlbfs analysis reusable
Hello, > [...] > As you probably noticed, I merged John patch. > Could you rebase this series on the main branch please? Of course. Only would you accept that for now I'll just keep the tests John has added? With the new helper, directory selection logic can be tested isolated from parsing and mkdir(), but we have little time until RC1. Tests can be improved anytime. > [...] > We are in a rather generic helper function. > Error messages should be logged by callers of this helper, because the > caller knows better what the impact of failing to list mountpoints is. > In the helper itself, this log should probably be info or debug level. > > If you think this error-level log should be kept in the helper, can you > make it a bit higher level so that users understand what is wrong and what > actions should be done to fix the situation? No, I agree that DEBUG is better for system errors. I don't often add generic code, but for Windos we log all system errors as DEBUG and higher-level as ERR. Will send v7, thanks.
Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
13/10/2021 10:51, Kinsella, Ray: > > On 12/10/2021 22:52, Thomas Monjalon wrote: > > 12/10/2021 22:34, Dumitrescu, Cristian: > >> From: Thomas Monjalon > >>> 01/09/2021 14:20, Jasvinder Singh: > These APIs were introduced in 18.05, therefore removing > experimental tag to promote them to stable state. > > Signed-off-by: Jasvinder Singh > --- > lib/pipeline/rte_port_in_action.h | 10 -- > lib/pipeline/rte_table_action.h | 18 -- > lib/pipeline/version.map | 16 ++-- > 3 files changed, 6 insertions(+), 38 deletions(-) > >>> > >>> Cristian, please can you check whether you intend to keep these functions > >>> in > >>> future? > >>> If they are candidate to be removed, there is no point to promote them. > >> > >> Hi Thomas, > >> > >> Yes, they are candidate for removal, as the new rte_swx_pipeline API > >> evolves. > >> > >> But removing them requires updating the drivers/net/softnic code to use > >> the new API, which is not going to be completed in time for release 21.11. > >> > >> So given this lag, it might be better to simply promote these functions to > >> stable API now, as Ray suggests, instead of continuing to keep them > >> experimental; then, once these functions are no longer used, then we can > >> remove them, most likely in 22.11. > >> > >> So I will ack these patches, but I am willing to reconsider if you feel > >> strongly against this approach. > > > > I think we should not promote API that we know will disappear soon. > > The stable status means something for the users. > > Ray, what is your opinion? > > > > Well - I agree with Cristian (he and I discuss this a few weeks ago). > My position is if you are going to maintain an API, that means giving a few > guarantees. > The API's have been experimental for 3 years ... at what point do they mature? > > However, I agree there is two ways to look at this thing, I try to be > pragmatic. > Maturing of any ABI/API is a conversation between a maintainer and the > contributor. > If they strongly feel, it is a pointless exercise - I won't argue. I think you did't get it. This API will be removed soon. That's why I think it doesn't make sense to make them stable, just before removing.
Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
On 13/10/2021 10:40, Thomas Monjalon wrote: > 13/10/2021 10:51, Kinsella, Ray: >> >> On 12/10/2021 22:52, Thomas Monjalon wrote: >>> 12/10/2021 22:34, Dumitrescu, Cristian: From: Thomas Monjalon > 01/09/2021 14:20, Jasvinder Singh: >> These APIs were introduced in 18.05, therefore removing >> experimental tag to promote them to stable state. >> >> Signed-off-by: Jasvinder Singh >> --- >> lib/pipeline/rte_port_in_action.h | 10 -- >> lib/pipeline/rte_table_action.h | 18 -- >> lib/pipeline/version.map | 16 ++-- >> 3 files changed, 6 insertions(+), 38 deletions(-) > > Cristian, please can you check whether you intend to keep these functions > in > future? > If they are candidate to be removed, there is no point to promote them. Hi Thomas, Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves. But removing them requires updating the drivers/net/softnic code to use the new API, which is not going to be completed in time for release 21.11. So given this lag, it might be better to simply promote these functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11. So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach. >>> >>> I think we should not promote API that we know will disappear soon. >>> The stable status means something for the users. >>> Ray, what is your opinion? >>> >> >> Well - I agree with Cristian (he and I discuss this a few weeks ago). >> My position is if you are going to maintain an API, that means giving a few >> guarantees. >> The API's have been experimental for 3 years ... at what point do they >> mature? >> >> However, I agree there is two ways to look at this thing, I try to be >> pragmatic. >> Maturing of any ABI/API is a conversation between a maintainer and the >> contributor. >> If they strongly feel, it is a pointless exercise - I won't argue. > > I think you did't get it. > This API will be removed soon. > That's why I think it doesn't make sense to make them stable, just before > removing. > Nope, I got it 110% I reflected both my opinion as ABI Maintainer, and tried to be pragmatic about the situation. As I said "Maturing of any ABI/API is a conversation between a maintainer and the contributor. If they strongly feel, it is a pointless exercise - I won't argue." Ray K
Re: [dpdk-dev] [PATCH v1 1/1] ci: enable DPDK GHA for arm64 with self-hosted runners
13/10/2021 10:03, Serena He:
> CI jobs are triggered only for repos installed with given GHApp and runners
[...]
> +# Here, runners for arm64 are accessed by installed GitHub APP, thus
> will not be available by fork.
> +# you can change the following 'if' and 'runs-on' if you have your own
> runners installed.
> +# or request to get your repo on the whitelist to use GitHub APP and
> delete this 'if'.
> +if: ${{ github.repository == 'DPDK/dpdk' || github.repository ==
> 'ovsrobot/dpdk' }}
What is this "GitHub APP"?
Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
13/10/2021 11:43, Kinsella, Ray: > On 13/10/2021 10:40, Thomas Monjalon wrote: > > 13/10/2021 10:51, Kinsella, Ray: > >> On 12/10/2021 22:52, Thomas Monjalon wrote: > >>> 12/10/2021 22:34, Dumitrescu, Cristian: > From: Thomas Monjalon > > 01/09/2021 14:20, Jasvinder Singh: > >> These APIs were introduced in 18.05, therefore removing > >> experimental tag to promote them to stable state. > >> > >> Signed-off-by: Jasvinder Singh > >> --- > >> lib/pipeline/rte_port_in_action.h | 10 -- > >> lib/pipeline/rte_table_action.h | 18 -- > >> lib/pipeline/version.map | 16 ++-- > >> 3 files changed, 6 insertions(+), 38 deletions(-) > > > > Cristian, please can you check whether you intend to keep these > > functions in > > future? > > If they are candidate to be removed, there is no point to promote them. > > Hi Thomas, > > Yes, they are candidate for removal, as the new rte_swx_pipeline API > evolves. > > But removing them requires updating the drivers/net/softnic code to use > the new API, which is not going to be completed in time for release > 21.11. > > So given this lag, it might be better to simply promote these functions > to stable API now, as Ray suggests, instead of continuing to keep them > experimental; then, once these functions are no longer used, then we can > remove them, most likely in 22.11. > > So I will ack these patches, but I am willing to reconsider if you feel > strongly against this approach. > >>> > >>> I think we should not promote API that we know will disappear soon. > >>> The stable status means something for the users. > >>> Ray, what is your opinion? > >>> > >> > >> Well - I agree with Cristian (he and I discuss this a few weeks ago). > >> My position is if you are going to maintain an API, that means giving a > >> few guarantees. > >> The API's have been experimental for 3 years ... at what point do they > >> mature? > >> > >> However, I agree there is two ways to look at this thing, I try to be > >> pragmatic. > >> Maturing of any ABI/API is a conversation between a maintainer and the > >> contributor. > >> If they strongly feel, it is a pointless exercise - I won't argue. > > > > I think you did't get it. > > This API will be removed soon. > > That's why I think it doesn't make sense to make them stable, just before > > removing. > > > > Nope, I got it 110% > I reflected both my opinion as ABI Maintainer, and tried to be pragmatic > about the situation. > > As I said "Maturing of any ABI/API is a conversation between a maintainer and > the contributor. > If they strongly feel, it is a pointless exercise - I won't argue." Sorry, I don't understand your position. Do you think we should promote functions to stable which are candidate to be removed soon?
Re: [dpdk-dev] [PATCH v2] ip_frag: fix fragmenting IPv4 fragment
Hi,Konstantin Meanwhile, as I said before, it would be really good to add a new test-case to cover that case. It could be a new separate patch on top of current one. --Ok,I will. Kevin
Re: [dpdk-dev] [PATCH v2 2/3] app/testpmd: support PPPoL2TPv2oUDP RSS Hash
> -Original Message-
> From: Ori Kam
> Sent: Wednesday, October 13, 2021 5:15 PM
> To: Wang, Jie1X ; dev@dpdk.org
> Cc: Yigit, Ferruh ; NBU-Contact-Thomas Monjalon
> ; andrew.rybche...@oktetlabs.ru; Li, Xiaoyun
> ; Yang, SteveX ; Wu, Jingjing
> ; Xing, Beilei ; Wu, Wenjun1
>
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] app/testpmd: support PPPoL2TPv2oUDP
> RSS Hash
>
> Hi Wang,
>
> > -Original Message-
> > From: Wang, Jie1X
> > Sent: Wednesday, October 13, 2021 11:16 AM
> >
> > Subject: RE: [dpdk-dev] [PATCH v2 2/3] app/testpmd: support
> > PPPoL2TPv2oUDP RSS Hash
> >
> >
> >
> > > -Original Message-
> > > From: Ori Kam
> > > Sent: Tuesday, October 12, 2021 11:32 PM
> > > To: Wang, Jie1X ; dev@dpdk.org
> > > Cc: Yigit, Ferruh ; NBU-Contact-Thomas
> > > Monjalon ; andrew.rybche...@oktetlabs.ru; Li,
> > > Xiaoyun ; Yang, SteveX
> > > ; Wu, Jingjing ; Xing,
> > > Beilei ; Wu, Wenjun1
> > > Subject: RE: [dpdk-dev] [PATCH v2 2/3] app/testpmd: support
> > > PPPoL2TPv2oUDP RSS Hash
> > >
> > > Hi Jie,
> > >
> > > > -Original Message-
> > > > From: dev On Behalf Of Jie Wang
> > > > Sent: Tuesday, October 12, 2021 1:25 PM
> > > > Subject: [dpdk-dev] [PATCH v2 2/3] app/testpmd: support
> > > > PPPoL2TPv2oUDP RSS Hash
> > > >
> > > > Add support for test-pmd to parse protocol pattern L2TPv2 and PPP.
> > > >
> > > > Signed-off-by: Wenjun Wu
> > > > Signed-off-by: Jie Wang
> > > > ---
> > > > app/test-pmd/cmdline_flow.c | 34
> > > > ++
> > > > 1 file changed, 34 insertions(+)
> > > >
> > > > diff --git a/app/test-pmd/cmdline_flow.c
> > > > b/app/test-pmd/cmdline_flow.c index
> > > > bb22294dd3..3c9bcabd97 100644
> > > > --- a/app/test-pmd/cmdline_flow.c
> > > > +++ b/app/test-pmd/cmdline_flow.c
> > > > @@ -299,6 +299,8 @@ enum index {
> > > > ITEM_GENEVE_OPT_TYPE,
> > > > ITEM_GENEVE_OPT_LENGTH,
> > > > ITEM_GENEVE_OPT_DATA,
> > > > + ITEM_PPP,
> > > > + ITEM_L2TPV2,
> > > > ITEM_INTEGRITY,
> > > > ITEM_INTEGRITY_LEVEL,
> > > > ITEM_INTEGRITY_VALUE,
> > > > @@ -997,6 +999,8 @@ static const enum index next_item[] = {
> > > > ITEM_AH,
> > > > ITEM_PFCP,
> > > > ITEM_ECPRI,
> > > > + ITEM_PPP,
> > > > + ITEM_L2TPV2,
> > >
> > > Why in the middle?
> > >
> >
> > Ok, I will update it.
> >
> > > > ITEM_GENEVE_OPT,
> > > > ITEM_INTEGRITY,
> > > > ITEM_CONNTRACK,
> > > > @@ -1368,6 +1372,16 @@ static const enum index item_integrity_lv[] = {
> > > > ZERO,
> > > > };
> > > >
> > > > +static const enum index item_ppp[] = {
> > > > + ITEM_NEXT,
> > > > + ZERO,
> > > > +};
> > > > +
> > > > +static const enum index item_l2tpv2[] = {
> > > > + ITEM_NEXT,
> > > > + ZERO,
> > > > +};
> > > > +
> > > > static const enum index next_action[] = {
> > > > ACTION_END,
> > > > ACTION_VOID,
> > > > @@ -3579,6 +3593,20 @@ static const struct token token_list[] = {
> > > > (sizeof(struct
> > > > rte_flow_item_geneve_opt),
> > > > ITEM_GENEVE_OPT_DATA_SIZE)),
> > > > },
> > > > + [ITEM_PPP] = {
> > > > + .name = "ppp",
> > > > + .help = "match ppp header",
> > > > + .priv = PRIV_ITEM(PPP, sizeof(struct
> > > > rte_flow_item_ppp)),
> > > > + .next = NEXT(item_ppp),
> > > > + .call = parse_vc,
> > > > + },
> > > > + [ITEM_L2TPV2] = {
> > > > + .name = "l2tpv2",
> > > > + .help = "match l2tpv2 header",
> > > > + .priv = PRIV_ITEM(L2TPV2, sizeof(struct
> > > > rte_flow_item_l2tpv2)),
> > > > + .next = NEXT(item_l2tpv2),
> > > > + .call = parse_vc,
> > > > + },
> > > > [ITEM_INTEGRITY] = {
> > > > .name = "integrity",
> > > > .help = "match packet integrity", @@ -8343,6 +8371,12 @@
> > > > flow_item_default_mask(const struct
> > > rte_flow_item *item)
> > > > case RTE_FLOW_ITEM_TYPE_PFCP:
> > > > mask = &rte_flow_item_pfcp_mask;
> > > > break;
> > > > + case RTE_FLOW_ITEM_TYPE_L2TPV2:
> > > > + mask = &rte_flow_item_l2tpv2_mask;
> > > > + break;
> > > > + case RTE_FLOW_ITEM_TYPE_PPP:
> > > > + mask = &rte_flow_item_ppp_mask;
> > > > + break;
> > > > default:
> > > > break;
> > > > }
> > > > --
> > > > 2.25.1
> > >
> > > Maybe I'm missing something but I don't see that you added the
> > > ability to match on any of the header fields value.
> > > You also didn't update the code of encap (from my understanding this
> > > is a tunnel
> > > header)
> > >
> > > Best,
> > > Ori
> >
> > Hi Ori,
> >
> > This feature is only support for iavf enable PPPoL2TPv2oUDP rss. So it
> > doesn't need to add the ability
Re: [dpdk-dev] [PATCH 1/2] vdpa/mlx5: workaround FW first completion in start
Hi Xueming, On 9/23/21 10:17, Xueming Li wrote: After a vDPA application restart, qemu restores VQ with used and available index, new incoming packet triggers virtio driver to handle buffers. Under heavy traffic, no available buffer for firmware to receive new packets, no Rx interrupts generated, driver is stuck on endless interrupt waiting. As a firmware workaround, this patch sends a notification after VQ setup to ask driver handling buffers and filling new buffers. Signed-off-by: Xueming Li Reviewed-by: Matan Azrad --- drivers/vdpa/mlx5/mlx5_vdpa_virtq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/vdpa/mlx5/mlx5_vdpa_virtq.c b/drivers/vdpa/mlx5/mlx5_vdpa_virtq.c index f530646058..71470d23d9 100644 --- a/drivers/vdpa/mlx5/mlx5_vdpa_virtq.c +++ b/drivers/vdpa/mlx5/mlx5_vdpa_virtq.c @@ -4,6 +4,7 @@ #include #include #include +#include #include #include @@ -367,6 +368,9 @@ mlx5_vdpa_virtq_setup(struct mlx5_vdpa_priv *priv, int index) goto error; } virtq->stopped = false; + /* Initial notification to ask qemu handling completed buffers. */ + if (virtq->eqp.cq.callfd != -1) + eventfd_write(virtq->eqp.cq.callfd, (eventfd_t)1); DRV_LOG(DEBUG, "vid %u virtq %u was created successfully.", priv->vid, index); return 0; Maybe this patch should be backported to stable branch? If so, could you reply with the Fixes tag so that I can add it while applying? Thanks, Maxime
Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
On 13/10/2021 10:49, Thomas Monjalon wrote: > 13/10/2021 11:43, Kinsella, Ray: >> On 13/10/2021 10:40, Thomas Monjalon wrote: >>> 13/10/2021 10:51, Kinsella, Ray: On 12/10/2021 22:52, Thomas Monjalon wrote: > 12/10/2021 22:34, Dumitrescu, Cristian: >> From: Thomas Monjalon >>> 01/09/2021 14:20, Jasvinder Singh: These APIs were introduced in 18.05, therefore removing experimental tag to promote them to stable state. Signed-off-by: Jasvinder Singh --- lib/pipeline/rte_port_in_action.h | 10 -- lib/pipeline/rte_table_action.h | 18 -- lib/pipeline/version.map | 16 ++-- 3 files changed, 6 insertions(+), 38 deletions(-) >>> >>> Cristian, please can you check whether you intend to keep these >>> functions in >>> future? >>> If they are candidate to be removed, there is no point to promote them. >> >> Hi Thomas, >> >> Yes, they are candidate for removal, as the new rte_swx_pipeline API >> evolves. >> >> But removing them requires updating the drivers/net/softnic code to use >> the new API, which is not going to be completed in time for release >> 21.11. >> >> So given this lag, it might be better to simply promote these functions >> to stable API now, as Ray suggests, instead of continuing to keep them >> experimental; then, once these functions are no longer used, then we can >> remove them, most likely in 22.11. >> >> So I will ack these patches, but I am willing to reconsider if you feel >> strongly against this approach. > > I think we should not promote API that we know will disappear soon. > The stable status means something for the users. > Ray, what is your opinion? > Well - I agree with Cristian (he and I discuss this a few weeks ago). My position is if you are going to maintain an API, that means giving a few guarantees. The API's have been experimental for 3 years ... at what point do they mature? However, I agree there is two ways to look at this thing, I try to be pragmatic. Maturing of any ABI/API is a conversation between a maintainer and the contributor. If they strongly feel, it is a pointless exercise - I won't argue. >>> >>> I think you did't get it. >>> This API will be removed soon. >>> That's why I think it doesn't make sense to make them stable, just before >>> removing. >>> >> >> Nope, I got it 110% >> I reflected both my opinion as ABI Maintainer, and tried to be pragmatic >> about the situation. >> >> As I said "Maturing of any ABI/API is a conversation between a maintainer >> and the contributor. >> If they strongly feel, it is a pointless exercise - I won't argue." > > Sorry, I don't understand your position. > Do you think we should promote functions to stable which are candidate to be > removed soon? > I am just reflecting the policy here. "An API’s experimental status should be reviewed annually, by both the maintainer and/or the original contributor. Ordinarily APIs marked as experimental will be promoted to the stable ABI once a maintainer has become satisfied that the API is mature and is unlikely to change." then, "The promotion or removal of symbols will typically form part of a conversation between the maintainer and the original contributor.". As I said, in my email above ... "Maturing of any ABI/API is a conversation between a maintainer and the contributor. If they strongly feel, it is a pointless exercise [to make the symbols stable] - I won't argue. Or to be _abundantly clear_ ... I don't think we should promote functions needlessly, as I said, if others decide it is pointless, I won't argue. I do think if we have a policy, that experimental symbols will mature or be removed, we should be careful about the exceptions we make, lest the policy becomes irrelevant and ignored. Ray K
Re: [dpdk-dev] [PATCH 2/2] vdpa/mlx5: retry VAR allocation during vDPA restart
On 9/23/21 10:17, Xueming Li wrote:
VAR is the device memory space for the virtio queues doorbells, qemu
could mmap it to directly to speed up doorbell push.
On a busy system, Qemu takes time to release VAR resources during driver
shutdown. If vdpa restarted quickly, the VAR allocation failed with
error 28 since the VAR is singleton resource per device.
This patch adds retry mechanism for VAR allocation.
Signed-off-by: Xueming Li
Reviewed-by: Matan Azrad
---
drivers/vdpa/mlx5/mlx5_vdpa.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/mlx5_vdpa.c b/drivers/vdpa/mlx5/mlx5_vdpa.c
index 6d17d7a6f3..991739e984 100644
--- a/drivers/vdpa/mlx5/mlx5_vdpa.c
+++ b/drivers/vdpa/mlx5/mlx5_vdpa.c
@@ -693,7 +693,14 @@ mlx5_vdpa_dev_probe(struct rte_device *dev)
if (attr.num_lag_ports == 0)
priv->num_lag_ports = 1;
priv->ctx = ctx;
- priv->var = mlx5_glue->dv_alloc_var(ctx, 0);
+ for (retry = 0; retry < 7; retry++) {
+ priv->var = mlx5_glue->dv_alloc_var(ctx, 0);
+ if (priv->var != NULL)
+ break;
+ DRV_LOG(WARNING, "Failed to allocate VAR, retry %d.\n", retry);
+ /* Wait Qemu release VAR during vdpa restart, 0.1 sec based. */
+ usleep(10U << retry);
+ }
if (!priv->var) {
DRV_LOG(ERR, "Failed to allocate VAR %u.", errno);
goto error;
That looks fragile, but at least we have a warning we can rely on.
Shouldn't we have a way to wait for Qemu to release the resources at
vdpa driver shutdown time?
Also as on patch 1, please add a Fixes tag it you want it to be
backported.
Regards,
Maxime
Re: [dpdk-dev] [PATCH 2/2] vdpa/mlx5: retry VAR allocation during vDPA restart
On Wed, 2021-10-13 at 12:06 +0200, Maxime Coquelin wrote:
>
> On 9/23/21 10:17, Xueming Li wrote:
> > VAR is the device memory space for the virtio queues doorbells, qemu
> > could mmap it to directly to speed up doorbell push.
> >
> > On a busy system, Qemu takes time to release VAR resources during driver
> > shutdown. If vdpa restarted quickly, the VAR allocation failed with
> > error 28 since the VAR is singleton resource per device.
> >
> > This patch adds retry mechanism for VAR allocation.
> >
> > Signed-off-by: Xueming Li
> > Reviewed-by: Matan Azrad
> > ---
> > drivers/vdpa/mlx5/mlx5_vdpa.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/vdpa/mlx5/mlx5_vdpa.c b/drivers/vdpa/mlx5/mlx5_vdpa.c
> > index 6d17d7a6f3..991739e984 100644
> > --- a/drivers/vdpa/mlx5/mlx5_vdpa.c
> > +++ b/drivers/vdpa/mlx5/mlx5_vdpa.c
> > @@ -693,7 +693,14 @@ mlx5_vdpa_dev_probe(struct rte_device *dev)
> > if (attr.num_lag_ports == 0)
> > priv->num_lag_ports = 1;
> > priv->ctx = ctx;
> > - priv->var = mlx5_glue->dv_alloc_var(ctx, 0);
> > + for (retry = 0; retry < 7; retry++) {
> > + priv->var = mlx5_glue->dv_alloc_var(ctx, 0);
> > + if (priv->var != NULL)
> > + break;
> > + DRV_LOG(WARNING, "Failed to allocate VAR, retry %d.\n", retry);
> > + /* Wait Qemu release VAR during vdpa restart, 0.1 sec based. */
> > + usleep(10U << retry);
> > + }
> > if (!priv->var) {
> > DRV_LOG(ERR, "Failed to allocate VAR %u.", errno);
> > goto error;
> >
>
> That looks fragile, but at least we have a warning we can rely on.
> Shouldn't we have a way to wait for Qemu to release the resources at
> vdpa driver shutdown time?
If dpdk-vdpa get killed and restart, qemu will shutdown device and
unmap the resources independently.
>
> Also as on patch 1, please add a Fixes tag it you want it to be
> backported.
Agree to backport, but not a fix, I'll add cc:sta...@dpdk.org, the
patch will be noticed by maintainer, thanks for the suggestion!
>
> Regards,
> Maxime
>
Re: [dpdk-dev] [PATCH v12 2/2] app/testpmd: fix testpmd doesn't show RSS hash offload
On 10/13/2021 9:50 AM, Ferruh Yigit wrote:
On 10/13/2021 3:42 AM, Wang, Jie1X wrote:
-Original Message-
From: Yigit, Ferruh
Sent: Tuesday, October 12, 2021 10:38 PM
To: Wang, Jie1X ; dev@dpdk.org
Cc: tho...@monjalon.net; andrew.rybche...@oktetlabs.ru; Li, Xiaoyun
; Yang, SteveX
Subject: Re: [PATCH v12 2/2] app/testpmd: fix testpmd doesn't show RSS hash
offload
On 10/12/2021 3:54 AM, Jie Wang wrote:
The driver may change offloads info into dev->data->dev_conf in
dev_configure which may cause port->dev_conf and port->rx_conf contain
outdated values.
This patch updates the offloads info if it changes to fix this issue.
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Signed-off-by: Jie Wang
Hi Jie,
ci/intel-Testing is still reporting some errors [1] with this patch, did you
able to
investigate the reason of it?
This error seems not seen in other patches, so that shouldn't be an
infrastructure
problem.
[1]
http://mails.dpdk.org/archives/test-report/2021-October/226766.html
Hi Ferruh,
When the dpdk runs the test_pf_tx_rx_queue test case, the port will be
configured with rxq/txq to 1. This will cause the test to fail.
In rte_eth_dev_configure, if rxq/txq is 1, dev_conf->rxmode.mq_mode is ETH_MQ_RX_NONE, and
dev_conf->rxmode.offloads contains the DEV_RX_OFFLOAD_RSS_HASH value by default, which
causes the program to report an error " Ethdev port_id=0 config invalid Rx mq_mode without
RSS but RSS_HASH offload is requested".
When the port needs to configure txq/txq to 1, first clear the RSS_HASH
configuration of dev_conf->rxmode.offloads.
And I have talked about this error with the tester a few days ago, and they
will modify the test case. They will add a command (port config port_id
rx_offload rss_hash off) before configuring txq/rxq to 1.
I see, but shouldn't this fail for all patches, why it is only failing
for this set?
Got it now, in first config some PMDs force enables RSS_HASH, when testpmd
disables
the RSS later, the existing RSS_HASH request cause failure in ethdev layer.
What about disable the RSS_HASH in application level, when RSS is disables,
something
like following:
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index a7841c557f99..5f6daac8a616 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3601,12 +3601,15 @@ init_port_config(void)
}
if (port->dcb_flag == 0) {
- if( port->dev_conf.rx_adv_conf.rss_conf.rss_hf != 0)
+ if( port->dev_conf.rx_adv_conf.rss_conf.rss_hf != 0) {
port->dev_conf.rxmode.mq_mode =
(enum rte_eth_rx_mq_mode)
(rx_mq_mode & ETH_MQ_RX_RSS);
- else
+ } else {
port->dev_conf.rxmode.mq_mode = ETH_MQ_RX_NONE;
+ port->dev_conf.rxmode.offloads &=
+ ~DEV_RX_OFFLOAD_RSS_HASH;
+ }
}
rxtx_port_config(port);
Re: [dpdk-dev] [PATCH v6 2/3] eal: add memory pre-allocation from existing files
On Tue, Oct 12, 2021 at 11:09 PM Dmitry Kozlyuk wrote: > > From this, I see two parts in this patch: > > - faster restart, reusing hugepage files as is (combination of not calling > > unlink() and doing "clear on alloc"), > > This part is interesting, and I think a single knob for this would be > > enough. > > In combination with rte_extmem* API this know would indeed allow to implement > the feature in the app. However, the drawback is that all the logic to select > hugepage size, NUMA, and names would need to be done from the app, probably > with its own options. OTOH, there is already hugetlbfs and numactl to avoid > apps duplicating this logic. Also, it's not only the fast restart, but also > the fast initial start on a prepared system. How do you "prepare" a system? > > > - finegrained control of hugepage files, but it has the drawback of > > imposing primary/secondary run with the same options. > > The second part seems complex to configure. I see conflicts with > > existing options, so it seems a good way to get caught up in the carpet > > (sorry if it translates badly from French :p). > > I don't see why synchronizing memory options is a big issue. We have too many options for the memory subsystem. I mentionned --socket-mem, --huge-dir, --file-prefix. But there is also --huge-unlink, --no-shconf, --in-memory, --legacy-mem, --single-file-segments, --match-allocations and --socket-limit. Some of those do part of the job, others are incompatible with this new option and probably some are orthogonal. Sure we can add a new one that prepare your toasts, coffee and wake up the kids (that's progress!). Maybe you can provide an example on how this is used? Thanks. -- David Marchand
[dpdk-dev] [PATCH v4] cryptodev: add telemetry callbacks
The cryptodev library now registers commands with telemetry, and
implements the corresponding callback functions. These commands
allow a list of cryptodevs to be queried, as well as info and stats
for the corresponding cryptodev.
An example usage can be seen below:
Connecting to /var/run/dpdk/rte/dpdk_telemetry.v2
{"version": "DPDK 21.11.0-rc0", "pid": 1135019, "max_output_len": 16384}
--> /
{"/": ["/", "/cryptodev/info", "/cryptodev/list", "/cryptodev/stats", ...]}
--> /cryptodev/list
{"/cryptodev/list": [0,1,2,3]}
--> /cryptodev/info,0
{"/cryptodev/info": {"device_name": ":1c:01.0_qat_sym", \
"max_nb_queue_pairs": 2}}
--> /cryptodev/stats,0
{"/cryptodev/stats": {"enqueued_count": 0, "dequeued_count": 0, \
"enqueue_err_count": 0, "dequeue_err_count": 0}}
Signed-off-by: Rebecca Troy
---
v4:
- Corrected doc heading underline and link
- Replaced remaining -1 return values with -EINVAL
v3:
- Added missing version tag to patch.
v2:
- Added documentation and release notes.
- Changed the /cryptodev/list command to list the devices as an
array of IDs, rather than as names and IDs.
- Added the /cryptodev/info command as described above.
---
doc/guides/prog_guide/cryptodev_lib.rst | 28
doc/guides/rel_notes/release_21_11.rst | 5 ++
lib/cryptodev/rte_cryptodev.c | 92 +
3 files changed, 125 insertions(+)
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
b/doc/guides/prog_guide/cryptodev_lib.rst
index 9b1cf8d49f..25663e552e 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -1282,3 +1282,31 @@ Asymmetric Crypto Device API
The cryptodev Library API is described in the
`DPDK API Reference
Re: [dpdk-dev] [PATCH] net/ice/base: fix null pointer dereferences for parser
> -Original Message-
> From: Guo, Junfeng
> Sent: Wednesday, October 13, 2021 6:35 PM
> To: Zhang, Qi Z ; Wu, Jingjing ;
> Xing, Beilei
> Cc: dev@dpdk.org; sta...@dpdk.org; Yigit, Ferruh ;
> Guo, Junfeng
> Subject: [PATCH] net/ice/base: fix null pointer dereferences for parser
>
> Null-checking "p" suggests that it may be null, but it has already been
> dereferenced on all paths leading to the check. Thus correct the code lines
> and
> remove the redundant line.
>
> Fixes: c84f8aa2100c ("net/ice/base: add parser runtime skeleton")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Junfeng Guo
Acked-by: Qi Zhang
Applied to dpdk-next-net-intel.
Thanks
Qi
Re: [dpdk-dev] [PATCH] net/ice: fix compile failure when Rx desc size is 16
> -Original Message-
> From: Su, Simei
> Sent: Monday, October 11, 2021 4:36 PM
> To: Zhang, Qi Z
> Cc: dev@dpdk.org; Wu, Wenjun1 ; Su, Simei
>
> Subject: [PATCH] net/ice: fix compile failure when Rx desc size is 16
>
> The Timestamp Overlay feature is available only in 32B Flex Descriptors.
> This patch adds compile option when in 16B Flex Descriptors.
>
> Fixes: 953e74e6b73a ("net/ice: enable Rx timestamp on flex descriptor")
> Fixes: 646dcbe6c701 ("net/ice: support IEEE 1588 PTP")
>
> Signed-off-by: Simei Su
Acked-by: Qi Zhang
Applied to dpdk-next-net-intel.
Thanks
Qi
Re: [dpdk-dev] [PATCH v1] doc: fix typo of Intel device name
> -Original Message- > From: dev On Behalf Of William Tu > Sent: Tuesday, October 12, 2021 2:56 AM > To: dev@dpdk.org > Cc: Wang, Haiyue > Subject: [dpdk-dev] [PATCH v1] doc: fix typo of Intel device name > > The device name should be 82574L Gigabit Ethernet Controller. > > Signed-off-by: William Tu > Cc: Haiyue Wang > --- > doc/guides/nics/e1000em.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/guides/nics/e1000em.rst b/doc/guides/nics/e1000em.rst index > 041c9a09a3a5..b9249b62f3d6 100644 > --- a/doc/guides/nics/e1000em.rst > +++ b/doc/guides/nics/e1000em.rst > @@ -10,7 +10,7 @@ The DPDK EM poll mode driver supports the following > emulated devices: > > * VMware* emulated Intel® 82545EM Gigabit Ethernet Controller > > -* VMware emulated Intel® 8274L Gigabit Ethernet Controller. > +* VMware emulated Intel® 82574L Gigabit Ethernet Controller. > > Validated Hypervisors > - > -- > 2.33.0.windows.2 Applied to dpdk-next-net-intel after add "cc stable" tag. Thanks Qi
Re: [dpdk-dev] [PATCH v3 00/10] net/sfc: add support for tunnel offload
On 10/13/2021 1:24 AM, Ivan Malov wrote: The first 6 patches comprise the fundamental part of the series. They are trying to be future-proof with respect to the planned HW/FW changes. 4 more patches form the adaptation part of some sort to make the offload work on the currently available HW/FW. This patch series should be applied on top of another patch series named "A means to negotiate delivery of Rx meta data": https://patches.dpdk.org/project/dpdk/list/?series=19373 Changes in v2: * Rebase on top of v4 of the above mentioned patch series Changes in v3: * Rebase as per request by Ferruh Yigit Ivan Malov (10): net/sfc: fence off 8 bits in Rx mark for tunnel offload common/sfc_efx/base: add API to set RECIRC ID in outer rules net/sfc: support JUMP flows in tunnel offload common/sfc_efx/base: add RECIRC ID match in action rules API net/sfc: support GROUP flows in tunnel offload net/sfc: implement control path operations in tunnel offload net/sfc: override match on ETH in tunnel offload JUMP rules net/sfc: use action rules in tunnel offload JUMP rules net/sfc: support counters in tunnel offload JUMP rules net/sfc: refine pattern of GROUP flows in tunnel offload Hi Ivan, Two check scripts are failing, can you please check them: 1. $ ./devtools/check-doc-vs-code.sh rte_flow doc out of sync for sfc item mark action jump 2. $ ./devtools/check-meson.py Error: Incorrect indent at drivers/net/sfc/meson.build:93
Re: [dpdk-dev] [PATCH v3 00/10] net/sfc: add support for tunnel offload
On 10/13/2021 1:24 AM, Ivan Malov wrote: The first 6 patches comprise the fundamental part of the series. They are trying to be future-proof with respect to the planned HW/FW changes. 4 more patches form the adaptation part of some sort to make the offload work on the currently available HW/FW. This patch series should be applied on top of another patch series named "A means to negotiate delivery of Rx meta data": https://patches.dpdk.org/project/dpdk/list/?series=19373 Changes in v2: * Rebase on top of v4 of the above mentioned patch series Changes in v3: * Rebase as per request by Ferruh Yigit Ivan Malov (10): net/sfc: fence off 8 bits in Rx mark for tunnel offload common/sfc_efx/base: add API to set RECIRC ID in outer rules net/sfc: support JUMP flows in tunnel offload common/sfc_efx/base: add RECIRC ID match in action rules API net/sfc: support GROUP flows in tunnel offload net/sfc: implement control path operations in tunnel offload net/sfc: override match on ETH in tunnel offload JUMP rules net/sfc: use action rules in tunnel offload JUMP rules net/sfc: support counters in tunnel offload JUMP rules net/sfc: refine pattern of GROUP flows in tunnel offload The flow API action/pattern names are uppercase in the patch title, but I remember Thomas is converting them to lowercase in the main repo. @Thomas, @Ori, what is the preferred syntax in the patch title?
Re: [dpdk-dev] [PATCH] net/ice: fix deadlock on flow redirect
> -Original Message-
> From: Yu, DapengX
> Sent: Monday, October 11, 2021 3:39 PM
> To: Yang, Qiming ; Zhang, Qi Z
>
> Cc: dev@dpdk.org; Yu, DapengX ; sta...@dpdk.org
> Subject: [PATCH] net/ice: fix deadlock on flow redirect
>
> From: Dapeng Yu
>
> If flow redirect failed, the spinlock will not be unlocked.
> This patch fixes it.
>
> Fixes: bc9201388d56 ("net/ice: support flow redirect")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Dapeng Yu
Acked-by: Qi Zhang
Applied to dpdk-next-net-intel.
Thanks
Qi
Re: [dpdk-dev] [PATCH v3 00/10] net/sfc: add support for tunnel offload
13/10/2021 12:45, Ferruh Yigit: > On 10/13/2021 1:24 AM, Ivan Malov wrote: > > The first 6 patches comprise the fundamental part of the series. > > They are trying to be future-proof with respect to the planned > > HW/FW changes. 4 more patches form the adaptation part of some > > sort to make the offload work on the currently available HW/FW. > > > > This patch series should be applied on top of another patch > > series named "A means to negotiate delivery of Rx meta data": > > https://patches.dpdk.org/project/dpdk/list/?series=19373 > > > > Changes in v2: > > * Rebase on top of v4 of the above mentioned patch series > > > > Changes in v3: > > * Rebase as per request by Ferruh Yigit > > > > Ivan Malov (10): > >net/sfc: fence off 8 bits in Rx mark for tunnel offload > >common/sfc_efx/base: add API to set RECIRC ID in outer rules > >net/sfc: support JUMP flows in tunnel offload > >common/sfc_efx/base: add RECIRC ID match in action rules API > >net/sfc: support GROUP flows in tunnel offload > >net/sfc: implement control path operations in tunnel offload > >net/sfc: override match on ETH in tunnel offload JUMP rules > >net/sfc: use action rules in tunnel offload JUMP rules > >net/sfc: support counters in tunnel offload JUMP rules > >net/sfc: refine pattern of GROUP flows in tunnel offload > > > > The flow API action/pattern names are uppercase in the patch title, > but I remember Thomas is converting them to lowercase in the main repo. > > @Thomas, @Ori, what is the preferred syntax in the patch title? Why is it uppercase? I think uppercase is for acronyms.
Re: [dpdk-dev] [PATCH] net: promote ip6 external headers skip API as stable
07/10/2021 18:25, Kinsella, Ray:
>
> On 02/10/2021 10:40, David Marchand wrote:
> > On Fri, Sep 24, 2021 at 3:02 PM Olivier Matz wrote:
> >>
> >> This function is public since commit 8f0e4d6a78a5 ("net: export IPv6
> >> header extensions skip function") (2018), and is used by vmxnet3 driver.
> >> Promote it as stable.
> >>
> >> Signed-off-by: Olivier Matz
> > Acked-by: David Marchand
> Acked-by: Ray Kinsella
Rebased and applied, thanks.
It was the last experimental symbol in librte_net,
so I completely removed the EXPERIMENTAL block from the .map file.
Re: [dpdk-dev] [PATCH v4] cryptodev: add telemetry callbacks
>-Original Message-
>From: Troy, Rebecca
>Sent: Wednesday 13 October 2021 11:22
>To: dev@dpdk.org
>Cc: Power, Ciara ; Zhang, Roy Fan
>; Troy, Rebecca ; Akhil
>Goyal ; Doherty, Declan
>Subject: [PATCH v4] cryptodev: add telemetry callbacks
>
>The cryptodev library now registers commands with telemetry, and
>implements the corresponding callback functions. These commands allow a
>list of cryptodevs to be queried, as well as info and stats for the
>corresponding
>cryptodev.
>
>An example usage can be seen below:
>
>Connecting to /var/run/dpdk/rte/dpdk_telemetry.v2
>{"version": "DPDK 21.11.0-rc0", "pid": 1135019, "max_output_len": 16384}
>--> /
>{"/": ["/", "/cryptodev/info", "/cryptodev/list", "/cryptodev/stats", ...]}
>--> /cryptodev/list
>{"/cryptodev/list": [0,1,2,3]}
>--> /cryptodev/info,0
>{"/cryptodev/info": {"device_name": ":1c:01.0_qat_sym", \
>"max_nb_queue_pairs": 2}}
>--> /cryptodev/stats,0
>{"/cryptodev/stats": {"enqueued_count": 0, "dequeued_count": 0, \
> "enqueue_err_count": 0, "dequeue_err_count": 0}}
>
>Signed-off-by: Rebecca Troy
Acked-by: Ciara Power
Re: [dpdk-dev] [PATCH] net/ice: fix freeing queues on DCF device reset
> -Original Message-
> From: Yu, DapengX
> Sent: Monday, October 11, 2021 3:26 PM
> To: Yang, Qiming ; Zhang, Qi Z
>
> Cc: dev@dpdk.org; Yu, DapengX ; sta...@dpdk.org
> Subject: [PATCH] net/ice: fix freeing queues on DCF device reset
>
> From: Dapeng Yu
>
> In function ice_dcf_stop_queues(), RX queues and TX queues are actually not
> freed, so their pointers shall not be set to NULL when queues are stopped.
>
> This patch adds function call to free queues on DCF device close and reset,
The patch only add function call in device close but not reset.
> which also set the RX and TX queues' pointers to NULL on freeing queues, and
> avoids referring to the released resource when device is started again.
>
> Fixes: 1a86f4dbdf42 ("net/ice: support DCF device reset")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Dapeng Yu
Acked-by: Qi Zhang
Applied to dpdk-next-net-intel after refined the commit log.
Thanks
Qi
[dpdk-dev] [PATCH v4 0/4] net/mlx5: implicit mempool registration
MLX5 hardware has its internal IOMMU where PMD registers the memory. On the data path, PMD translates VA into a key consumed by the device IOMMU. It is impractical for the PMD to register all allocated memory because of increased lookup cost both in HW and SW. Most often mbuf memory comes from mempools, so if PMD tracks them, it can almost always have mbuf memory registered before an mbuf hits the PMD. This patchset adds such tracking in the PMD and internal API to support it. Please see [1] for the discussion of the patch 2/4 and how it can be useful outside of the MLX5 PMD. [1]: http://inbox.dpdk.org/dev/ch0pr12mb509112fadb778ab28af3771db9...@ch0pr12mb5091.namprd12.prod.outlook.com/ v4: (Andrew) 1. Improve mempool event callbacks unit tests and documentation. 2. Make MEMPOOL_F_NON_IO internal and automatically inferred. Add unit tests for the inference logic. v3: Improve wording and naming; fix typos (Thomas). v2 (internal review and testing): 1. Change tracked mempool event from being created (CREATE) to being fully populated (READY), which is the state PMD is interested in. 2. Unit test the new mempool callback API. 3. Remove bogus "error" messages in normal conditions. 4. Fixes in PMD. Dmitry Kozlyuk (4): mempool: add event callbacks mempool: add non-IO flag common/mlx5: add mempool registration facilities net/mlx5: support mempool registration app/test/test_mempool.c| 285 doc/guides/nics/mlx5.rst | 13 + doc/guides/rel_notes/release_21_11.rst | 9 + drivers/common/mlx5/mlx5_common_mp.c | 50 +++ drivers/common/mlx5/mlx5_common_mp.h | 14 + drivers/common/mlx5/mlx5_common_mr.c | 580 + drivers/common/mlx5/mlx5_common_mr.h | 17 + drivers/common/mlx5/version.map| 5 + drivers/net/mlx5/linux/mlx5_mp_os.c| 44 ++ drivers/net/mlx5/linux/mlx5_os.c | 4 +- drivers/net/mlx5/mlx5.c| 152 +++ drivers/net/mlx5/mlx5.h| 10 + drivers/net/mlx5/mlx5_mr.c | 120 ++--- drivers/net/mlx5/mlx5_mr.h | 2 - drivers/net/mlx5/mlx5_rx.h | 21 +- drivers/net/mlx5/mlx5_rxq.c| 13 + drivers/net/mlx5/mlx5_trigger.c| 77 +++- drivers/net/mlx5/windows/mlx5_os.c | 1 + lib/mempool/rte_mempool.c | 139 ++ lib/mempool/rte_mempool.h | 66 +++ lib/mempool/version.map| 8 + 21 files changed, 1514 insertions(+), 116 deletions(-) -- 2.25.1
[dpdk-dev] [PATCH v4 1/4] mempool: add event callbacks
Data path performance can benefit if the PMD knows which memory it will
need to handle in advance, before the first mbuf is sent to the PMD.
It is impractical, however, to consider all allocated memory for this
purpose. Most often mbuf memory comes from mempools that can come and
go. PMD can enumerate existing mempools on device start, but it also
needs to track creation and destruction of mempools after the forwarding
starts but before an mbuf from the new mempool is sent to the device.
Add an API to register callback for mempool life cycle events:
* rte_mempool_event_callback_register()
* rte_mempool_event_callback_unregister()
Currently tracked events are:
* RTE_MEMPOOL_EVENT_READY (after populating a mempool)
* RTE_MEMPOOL_EVENT_DESTROY (before freeing a mempool)
Provide a unit test for the new API.
The new API is internal, because it is primarily demanded by PMDs that
may need to deal with any mempools and do not control their creation,
while an application, on the other hand, knows which mempools it creates
and doesn't care about internal mempools PMDs might create.
Signed-off-by: Dmitry Kozlyuk
Acked-by: Matan Azrad
---
app/test/test_mempool.c | 209 ++
lib/mempool/rte_mempool.c | 137 +
lib/mempool/rte_mempool.h | 61 +++
lib/mempool/version.map | 8 ++
4 files changed, 415 insertions(+)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 7675a3e605..bc0cc9ed48 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -471,6 +472,206 @@ test_mp_mem_init(struct rte_mempool *mp,
data->ret = 0;
}
+struct test_mempool_events_data {
+ struct rte_mempool *mp;
+ enum rte_mempool_event event;
+ bool invoked;
+};
+
+static void
+test_mempool_events_cb(enum rte_mempool_event event,
+ struct rte_mempool *mp, void *user_data)
+{
+ struct test_mempool_events_data *data = user_data;
+
+ data->mp = mp;
+ data->event = event;
+ data->invoked = true;
+}
+
+static int
+test_mempool_events(int (*populate)(struct rte_mempool *mp))
+{
+ static const size_t CB_NUM = 3;
+ static const size_t MP_NUM = 2;
+
+ struct test_mempool_events_data data[CB_NUM];
+ struct rte_mempool *mp[MP_NUM];
+ char name[RTE_MEMPOOL_NAMESIZE];
+ size_t i, j;
+ int ret;
+
+ for (i = 0; i < CB_NUM; i++) {
+ ret = rte_mempool_event_callback_register
+ (test_mempool_events_cb, &data[i]);
+ RTE_TEST_ASSERT_EQUAL(ret, 0, "Failed to register the callback
%zu: %s",
+ i, rte_strerror(rte_errno));
+ }
+ ret = rte_mempool_event_callback_unregister(test_mempool_events_cb, mp);
+ RTE_TEST_ASSERT_NOT_EQUAL(ret, 0, "Unregistered a non-registered
callback");
+ /* NULL argument has no special meaning in this API. */
+ ret = rte_mempool_event_callback_unregister(test_mempool_events_cb,
+ NULL);
+ RTE_TEST_ASSERT_NOT_EQUAL(ret, 0, "Unregistered a non-registered
callback with NULL argument");
+
+ /* Create mempool 0 that will be observed by all callbacks. */
+ memset(&data, 0, sizeof(data));
+ strcpy(name, "empty0");
+ mp[0] = rte_mempool_create_empty(name, MEMPOOL_SIZE,
+MEMPOOL_ELT_SIZE, 0, 0,
+SOCKET_ID_ANY, 0);
+ RTE_TEST_ASSERT_NOT_NULL(mp[0], "Cannot create mempool %s: %s",
+name, rte_strerror(rte_errno));
+ for (j = 0; j < CB_NUM; j++)
+ RTE_TEST_ASSERT_EQUAL(data[j].invoked, false,
+ "Callback %zu invoked on %s mempool
creation",
+ j, name);
+
+ rte_mempool_set_ops_byname(mp[0], rte_mbuf_best_mempool_ops(), NULL);
+ ret = populate(mp[0]);
+ RTE_TEST_ASSERT_EQUAL(ret, (int)mp[0]->size, "Failed to populate
mempool %s: %s",
+ name, rte_strerror(rte_errno));
+ for (j = 0; j < CB_NUM; j++) {
+ RTE_TEST_ASSERT_EQUAL(data[j].invoked, true,
+ "Callback %zu not invoked on mempool %s
population",
+ j, name);
+ RTE_TEST_ASSERT_EQUAL(data[j].event,
+ RTE_MEMPOOL_EVENT_READY,
+ "Wrong callback invoked, expected
READY");
+ RTE_TEST_ASSERT_EQUAL(data[j].mp, mp[0],
+ "Callback %zu invoked for a wrong
mempool instead of %s",
+ j, name);
+ }
+
+ /* Check that unregistered callback 0 observes no events. */
+
[dpdk-dev] [PATCH v4 2/4] mempool: add non-IO flag
Mempool is a generic allocator that is not necessarily used for device
IO operations and its memory for DMA. Add MEMPOOL_F_NON_IO flag to mark
such mempools automatically if their objects are not contiguous
or IOVA are not available. Components can inspect this flag
in order to optimize their memory management.
Discussion: https://mails.dpdk.org/archives/dev/2021-August/216654.html
Signed-off-by: Dmitry Kozlyuk
Acked-by: Matan Azrad
---
app/test/test_mempool.c| 76 ++
doc/guides/rel_notes/release_21_11.rst | 3 +
lib/mempool/rte_mempool.c | 2 +
lib/mempool/rte_mempool.h | 5 ++
4 files changed, 86 insertions(+)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index bc0cc9ed48..15146dd737 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -672,6 +672,74 @@ test_mempool_events_safety(void)
return 0;
}
+static int
+test_mempool_flag_non_io_set_when_no_iova_contig_set(void)
+{
+ struct rte_mempool *mp;
+ int ret;
+
+ mp = rte_mempool_create_empty("empty", MEMPOOL_SIZE,
+ MEMPOOL_ELT_SIZE, 0, 0,
+ SOCKET_ID_ANY, MEMPOOL_F_NO_IOVA_CONTIG);
+ RTE_TEST_ASSERT_NOT_NULL(mp, "Cannot create mempool: %s",
+rte_strerror(rte_errno));
+ rte_mempool_set_ops_byname(mp, rte_mbuf_best_mempool_ops(), NULL);
+ ret = rte_mempool_populate_default(mp);
+ RTE_TEST_ASSERT(ret > 0, "Failed to populate mempool: %s",
+ rte_strerror(rte_errno));
+ RTE_TEST_ASSERT(mp->flags & MEMPOOL_F_NON_IO,
+ "NON_IO flag is not set when NO_IOVA_CONTIG is set");
+ rte_mempool_free(mp);
+ return 0;
+}
+
+static int
+test_mempool_flag_non_io_set_when_populated_with_bad_iova(void)
+{
+ void *addr;
+ size_t size = 1 << 16;
+ struct rte_mempool *mp;
+ int ret;
+
+ addr = rte_malloc("test_mempool", size, 0);
+ RTE_TEST_ASSERT_NOT_NULL(addr, "Cannot allocate memory");
+ mp = rte_mempool_create_empty("empty", MEMPOOL_SIZE,
+ MEMPOOL_ELT_SIZE, 0, 0,
+ SOCKET_ID_ANY, 0);
+ RTE_TEST_ASSERT_NOT_NULL(mp, "Cannot create mempool: %s",
+rte_strerror(rte_errno));
+ ret = rte_mempool_populate_iova(mp, addr, RTE_BAD_IOVA, size,
+ NULL, NULL);
+ /* The flag must be inferred even if population isn't full. */
+ RTE_TEST_ASSERT(ret > 0, "Failed to populate mempool: %s",
+ rte_strerror(rte_errno));
+ RTE_TEST_ASSERT(mp->flags & MEMPOOL_F_NON_IO,
+ "NON_IO flag is not set when mempool is populated with
RTE_BAD_IOVA");
+ rte_mempool_free(mp);
+ rte_free(addr);
+ return 0;
+}
+
+static int
+test_mempool_flag_non_io_unset_by_default(void)
+{
+ struct rte_mempool *mp;
+ int ret;
+
+ mp = rte_mempool_create_empty("empty", MEMPOOL_SIZE,
+ MEMPOOL_ELT_SIZE, 0, 0,
+ SOCKET_ID_ANY, 0);
+ RTE_TEST_ASSERT_NOT_NULL(mp, "Cannot create mempool: %s",
+rte_strerror(rte_errno));
+ ret = rte_mempool_populate_default(mp);
+ RTE_TEST_ASSERT_EQUAL(ret, (int)mp->size, "Failed to populate mempool:
%s",
+ rte_strerror(rte_errno));
+ RTE_TEST_ASSERT(!(mp->flags & MEMPOOL_F_NON_IO),
+ "NON_IO flag is set by default");
+ rte_mempool_free(mp);
+ return 0;
+}
+
static int
test_mempool(void)
{
@@ -854,6 +922,14 @@ test_mempool(void)
if (test_mempool_events_safety() < 0)
GOTO_ERR(ret, err);
+ /* test NON_IO flag inference */
+ if (test_mempool_flag_non_io_unset_by_default() < 0)
+ GOTO_ERR(ret, err);
+ if (test_mempool_flag_non_io_set_when_no_iova_contig_set() < 0)
+ GOTO_ERR(ret, err);
+ if (test_mempool_flag_non_io_set_when_populated_with_bad_iova() < 0)
+ GOTO_ERR(ret, err);
+
rte_mempool_list_dump(stdout);
ret = 0;
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index f643a61f44..74e0e6f495 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -226,6 +226,9 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* mempool: Added ``MEMPOOL_F_NON_IO`` flag to give a hint to DPDK components
+ that objects from this pool will not be used for device IO (e.g. DMA).
+
ABI Changes
---
diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index 51c0ba2931..2204f140b3 100644
--- a/lib/mempool/rt
[dpdk-dev] [PATCH v4 3/4] common/mlx5: add mempool registration facilities
Add internal API to register mempools, that is, to create memory
regions (MR) for their memory and store them in a separate database.
Implementation deals with multi-process, so that class drivers don't
need to. Each protection domain has its own database. Memory regions
can be shared within a database if they represent a single hugepage
covering one or more mempools entirely.
Add internal API to lookup an MR key for an address that belongs
to a known mempool. It is a responsibility of a class driver
to extract the mempool from an mbuf.
Signed-off-by: Dmitry Kozlyuk
Acked-by: Matan Azrad
---
drivers/common/mlx5/mlx5_common_mp.c | 50 +++
drivers/common/mlx5/mlx5_common_mp.h | 14 +
drivers/common/mlx5/mlx5_common_mr.c | 580 +++
drivers/common/mlx5/mlx5_common_mr.h | 17 +
drivers/common/mlx5/version.map | 5 +
5 files changed, 666 insertions(+)
diff --git a/drivers/common/mlx5/mlx5_common_mp.c
b/drivers/common/mlx5/mlx5_common_mp.c
index 673a7c31de..6dfc5535e0 100644
--- a/drivers/common/mlx5/mlx5_common_mp.c
+++ b/drivers/common/mlx5/mlx5_common_mp.c
@@ -54,6 +54,56 @@ mlx5_mp_req_mr_create(struct mlx5_mp_id *mp_id, uintptr_t
addr)
return ret;
}
+/**
+ * @param mp_id
+ * ID of the MP process.
+ * @param share_cache
+ * Shared MR cache.
+ * @param pd
+ * Protection domain.
+ * @param mempool
+ * Mempool to register or unregister.
+ * @param reg
+ * True to register the mempool, False to unregister.
+ */
+int
+mlx5_mp_req_mempool_reg(struct mlx5_mp_id *mp_id,
+ struct mlx5_mr_share_cache *share_cache, void *pd,
+ struct rte_mempool *mempool, bool reg)
+{
+ struct rte_mp_msg mp_req;
+ struct rte_mp_msg *mp_res;
+ struct rte_mp_reply mp_rep;
+ struct mlx5_mp_param *req = (struct mlx5_mp_param *)mp_req.param;
+ struct mlx5_mp_arg_mempool_reg *arg = &req->args.mempool_reg;
+ struct mlx5_mp_param *res;
+ struct timespec ts = {.tv_sec = MLX5_MP_REQ_TIMEOUT_SEC, .tv_nsec = 0};
+ enum mlx5_mp_req_type type;
+ int ret;
+
+ MLX5_ASSERT(rte_eal_process_type() == RTE_PROC_SECONDARY);
+ type = reg ? MLX5_MP_REQ_MEMPOOL_REGISTER :
+MLX5_MP_REQ_MEMPOOL_UNREGISTER;
+ mp_init_msg(mp_id, &mp_req, type);
+ arg->share_cache = share_cache;
+ arg->pd = pd;
+ arg->mempool = mempool;
+ ret = rte_mp_request_sync(&mp_req, &mp_rep, &ts);
+ if (ret) {
+ DRV_LOG(ERR, "port %u request to primary process failed",
+ mp_id->port_id);
+ return -rte_errno;
+ }
+ MLX5_ASSERT(mp_rep.nb_received == 1);
+ mp_res = &mp_rep.msgs[0];
+ res = (struct mlx5_mp_param *)mp_res->param;
+ ret = res->result;
+ if (ret)
+ rte_errno = -ret;
+ mlx5_free(mp_rep.msgs);
+ return ret;
+}
+
/**
* Request Verbs queue state modification to the primary process.
*
diff --git a/drivers/common/mlx5/mlx5_common_mp.h
b/drivers/common/mlx5/mlx5_common_mp.h
index 6829141fc7..527bf3cad8 100644
--- a/drivers/common/mlx5/mlx5_common_mp.h
+++ b/drivers/common/mlx5/mlx5_common_mp.h
@@ -14,6 +14,8 @@
enum mlx5_mp_req_type {
MLX5_MP_REQ_VERBS_CMD_FD = 1,
MLX5_MP_REQ_CREATE_MR,
+ MLX5_MP_REQ_MEMPOOL_REGISTER,
+ MLX5_MP_REQ_MEMPOOL_UNREGISTER,
MLX5_MP_REQ_START_RXTX,
MLX5_MP_REQ_STOP_RXTX,
MLX5_MP_REQ_QUEUE_STATE_MODIFY,
@@ -33,6 +35,12 @@ struct mlx5_mp_arg_queue_id {
uint16_t queue_id; /* DPDK queue ID. */
};
+struct mlx5_mp_arg_mempool_reg {
+ struct mlx5_mr_share_cache *share_cache;
+ void *pd; /* NULL for MLX5_MP_REQ_MEMPOOL_UNREGISTER */
+ struct rte_mempool *mempool;
+};
+
/* Pameters for IPC. */
struct mlx5_mp_param {
enum mlx5_mp_req_type type;
@@ -41,6 +49,8 @@ struct mlx5_mp_param {
RTE_STD_C11
union {
uintptr_t addr; /* MLX5_MP_REQ_CREATE_MR */
+ struct mlx5_mp_arg_mempool_reg mempool_reg;
+ /* MLX5_MP_REQ_MEMPOOL_(UN)REGISTER */
struct mlx5_mp_arg_queue_state_modify state_modify;
/* MLX5_MP_REQ_QUEUE_STATE_MODIFY */
struct mlx5_mp_arg_queue_id queue_id;
@@ -91,6 +101,10 @@ void mlx5_mp_uninit_secondary(const char *name);
__rte_internal
int mlx5_mp_req_mr_create(struct mlx5_mp_id *mp_id, uintptr_t addr);
__rte_internal
+int mlx5_mp_req_mempool_reg(struct mlx5_mp_id *mp_id,
+ struct mlx5_mr_share_cache *share_cache, void *pd,
+ struct rte_mempool *mempool, bool reg);
+__rte_internal
int mlx5_mp_req_queue_state_modify(struct mlx5_mp_id *mp_id,
struct mlx5_mp_arg_queue_state_modify *sm);
__rte_internal
diff --git a/drivers/common/mlx5/mlx5_common_mr.c
b/drivers/common/mlx5/mlx5_common_mr.c
index 98fe8698e2..2e039a4e70 100644
--- a/drivers/common/mlx5/ml
[dpdk-dev] [PATCH v4 4/4] net/mlx5: support mempool registration
When the first port in a given protection domain (PD) starts,
install a mempool event callback for this PD and register all existing
memory regions (MR) for it. When the last port in a PD closes,
remove the callback and unregister all mempools for this PD.
This behavior can be switched off with a new devarg: mr_mempool_reg_en.
On TX slow path, i.e. when an MR key for the address of the buffer
to send is not in the local cache, first try to retrieve it from
the database of registered mempools. Supported are direct and indirect
mbufs, as well as externally-attached ones from MLX5 MPRQ feature.
Lookup in the database of non-mempool memory is used as the last resort.
RX mempools are registered regardless of the devarg value.
On RX data path only the local cache and the mempool database is used.
If implicit mempool registration is disabled, these mempools
are unregistered at port stop, releasing the MRs.
Signed-off-by: Dmitry Kozlyuk
Acked-by: Matan Azrad
---
doc/guides/nics/mlx5.rst | 13 +++
doc/guides/rel_notes/release_21_11.rst | 6 +
drivers/net/mlx5/linux/mlx5_mp_os.c| 44 +++
drivers/net/mlx5/linux/mlx5_os.c | 4 +-
drivers/net/mlx5/mlx5.c| 152 +
drivers/net/mlx5/mlx5.h| 10 ++
drivers/net/mlx5/mlx5_mr.c | 120 +--
drivers/net/mlx5/mlx5_mr.h | 2 -
drivers/net/mlx5/mlx5_rx.h | 21 ++--
drivers/net/mlx5/mlx5_rxq.c| 13 +++
drivers/net/mlx5/mlx5_trigger.c| 77 +++--
drivers/net/mlx5/windows/mlx5_os.c | 1 +
12 files changed, 347 insertions(+), 116 deletions(-)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index bae73f42d8..106e32e1c4 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1001,6 +1001,19 @@ Driver options
Enabled by default.
+- ``mr_mempool_reg_en`` parameter [int]
+
+ A nonzero value enables implicit registration of DMA memory of all mempools
+ except those having ``MEMPOOL_F_NON_IO``. This flag is set automatically
+ for mempools populated with non-contiguous objects or those without IOVA.
+ The effect is that when a packet from a mempool is transmitted,
+ its memory is already registered for DMA in the PMD and no registration
+ will happen on the data path. The tradeoff is extra work on the creation
+ of each mempool and increased HW resource use if some mempools
+ are not used with MLX5 devices.
+
+ Enabled by default.
+
- ``representor`` parameter [list]
This parameter can be used to instantiate DPDK Ethernet devices from
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 74e0e6f495..b4126c450f 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -159,6 +159,12 @@ New Features
* Added tests to verify tunnel header verification in IPsec inbound.
* Added tests to verify inner checksum.
+* **Updated Mellanox mlx5 driver.**
+
+ Updated the Mellanox mlx5 driver with new features and improvements,
including:
+
+ * Added implicit mempool registration to avoid data path hiccups (opt-out).
+
Removed Items
-
diff --git a/drivers/net/mlx5/linux/mlx5_mp_os.c
b/drivers/net/mlx5/linux/mlx5_mp_os.c
index 3a4aa766f8..d2ac375a47 100644
--- a/drivers/net/mlx5/linux/mlx5_mp_os.c
+++ b/drivers/net/mlx5/linux/mlx5_mp_os.c
@@ -20,6 +20,45 @@
#include "mlx5_tx.h"
#include "mlx5_utils.h"
+/**
+ * Handle a port-agnostic message.
+ *
+ * @return
+ * 0 on success, 1 when message is not port-agnostic, (-1) on error.
+ */
+static int
+mlx5_mp_os_handle_port_agnostic(const struct rte_mp_msg *mp_msg,
+ const void *peer)
+{
+ struct rte_mp_msg mp_res;
+ struct mlx5_mp_param *res = (struct mlx5_mp_param *)mp_res.param;
+ const struct mlx5_mp_param *param =
+ (const struct mlx5_mp_param *)mp_msg->param;
+ const struct mlx5_mp_arg_mempool_reg *mpr;
+ struct mlx5_mp_id mp_id;
+
+ switch (param->type) {
+ case MLX5_MP_REQ_MEMPOOL_REGISTER:
+ mlx5_mp_id_init(&mp_id, param->port_id);
+ mp_init_msg(&mp_id, &mp_res, param->type);
+ mpr = ¶m->args.mempool_reg;
+ res->result = mlx5_mr_mempool_register(mpr->share_cache,
+ mpr->pd, mpr->mempool,
+ NULL);
+ return rte_mp_reply(&mp_res, peer);
+ case MLX5_MP_REQ_MEMPOOL_UNREGISTER:
+ mlx5_mp_id_init(&mp_id, param->port_id);
+ mp_init_msg(&mp_id, &mp_res, param->type);
+ mpr = ¶m->args.mempool_reg;
+ res->result = mlx5_mr_mempool_unregister(mpr->share_cache,
+mpr->mempool, NULL);
+ return rte_mp_reply(&mp_res, peer);
+
Re: [dpdk-dev] [v6] telemetry: remove limitation on JSON output buffer length
>-Original Message-
>From: Gowrishankar Muthukrishnan
>Sent: Monday 11 October 2021 11:55
>To: dev@dpdk.org
>Cc: Richardson, Bruce ; Power, Ciara
>; jer...@marvell.com; Gowrishankar Muthukrishnan
>
>Subject: [v6] telemetry: remove limitation on JSON output buffer length
>
>Earlier, JSON message length was limited to 1024 which would not allow data
>more than this size. Removed this limitation by creating output buffer based
>on requested data length.
>
>Fixes: 52af6ccb2b39 ("telemetry: add utility functions for creating JSON")
>
>Signed-off-by: Gowrishankar Muthukrishnan
>---
Thanks,
Acked-by: Ciara Power
Re: [dpdk-dev] [PATCH] mempool: fix name size in mempool structure
On Wed, Oct 13, 2021 at 10:57 AM Andrew Rybchenko
wrote:
>
> Use correct define as a name array size.
>
> The change breaks ABI and therefore cannot be backported to
> stable branches.
>
> Fixes: 38c9817ee1d8 ("mempool: adjust name size in related data types")
>
> Signed-off-by: Andrew Rybchenko
Reviewed-by: David Marchand
Good catch, I guess we can clean ring too, quick grep:
lib/ring/rte_ring_core.h-struct rte_ring {
lib/ring/rte_ring_core.h- /*
lib/ring/rte_ring_core.h:* Note: this field kept the
RTE_MEMZONE_NAMESIZE size due to ABI
lib/ring/rte_ring_core.h-* compatibility requirements, it
could be changed to RTE_RING_NAMESIZE
lib/ring/rte_ring_core.h:* next time the ABI changes
lib/ring/rte_ring_core.h-*/
lib/ring/rte_ring_core.h- char name[RTE_MEMZONE_NAMESIZE]
__rte_cache_aligned;
--
David Marchand
Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
On Wed, Oct 13, 2021 at 11:02:02AM +0100, Kinsella, Ray wrote: > > > On 13/10/2021 10:49, Thomas Monjalon wrote: > > 13/10/2021 11:43, Kinsella, Ray: > >> On 13/10/2021 10:40, Thomas Monjalon wrote: > >>> 13/10/2021 10:51, Kinsella, Ray: > On 12/10/2021 22:52, Thomas Monjalon wrote: > > 12/10/2021 22:34, Dumitrescu, Cristian: > >> From: Thomas Monjalon > >>> 01/09/2021 14:20, Jasvinder Singh: > These APIs were introduced in 18.05, therefore removing > experimental tag to promote them to stable state. > > Signed-off-by: Jasvinder Singh > --- > lib/pipeline/rte_port_in_action.h | 10 -- > lib/pipeline/rte_table_action.h | 18 -- > lib/pipeline/version.map | 16 ++-- > 3 files changed, 6 insertions(+), 38 deletions(-) > >>> > >>> Cristian, please can you check whether you intend to keep these > >>> functions in > >>> future? > >>> If they are candidate to be removed, there is no point to promote > >>> them. > >> > >> Hi Thomas, > >> > >> Yes, they are candidate for removal, as the new rte_swx_pipeline API > >> evolves. > >> > >> But removing them requires updating the drivers/net/softnic code to > >> use the new API, which is not going to be completed in time for > >> release 21.11. > >> > >> So given this lag, it might be better to simply promote these > >> functions to stable API now, as Ray suggests, instead of continuing to > >> keep them experimental; then, once these functions are no longer used, > >> then we can remove them, most likely in 22.11. > >> > >> So I will ack these patches, but I am willing to reconsider if you > >> feel strongly against this approach. > > > > I think we should not promote API that we know will disappear soon. > > The stable status means something for the users. > > Ray, what is your opinion? > > > > Well - I agree with Cristian (he and I discuss this a few weeks ago). > My position is if you are going to maintain an API, that means giving a > few guarantees. > The API's have been experimental for 3 years ... at what point do they > mature? > > However, I agree there is two ways to look at this thing, I try to be > pragmatic. > Maturing of any ABI/API is a conversation between a maintainer and the > contributor. > If they strongly feel, it is a pointless exercise - I won't argue. > >>> > >>> I think you did't get it. > >>> This API will be removed soon. > >>> That's why I think it doesn't make sense to make them stable, just before > >>> removing. > >>> > >> > >> Nope, I got it 110% > >> I reflected both my opinion as ABI Maintainer, and tried to be pragmatic > >> about the situation. > >> > >> As I said "Maturing of any ABI/API is a conversation between a maintainer > >> and the contributor. > >> If they strongly feel, it is a pointless exercise - I won't argue." > > > > Sorry, I don't understand your position. > > Do you think we should promote functions to stable which are candidate to > > be removed soon? > > > > I am just reflecting the policy here. > > "An API’s experimental status should be reviewed annually, by both the > maintainer and/or the original contributor. Ordinarily APIs marked as > experimental will be promoted to the stable ABI once a maintainer has become > satisfied that the API is mature and is unlikely to change." > If an API is planned for removal, then I think it falls under the bucket of "likely to change", so should not be made non-experimental. Therefore I'd agree with Thomas view on this - not so much that promoting them is pointless, but I'd actually view it as harmful in encouraging use that will be broken in future. /Bruce
Re: [dpdk-dev] [PATCH] mempool: fix name size in mempool structure
On 10/13/21 2:07 PM, David Marchand wrote:
> On Wed, Oct 13, 2021 at 10:57 AM Andrew Rybchenko
> wrote:
>>
>> Use correct define as a name array size.
>>
>> The change breaks ABI and therefore cannot be backported to
>> stable branches.
>>
>> Fixes: 38c9817ee1d8 ("mempool: adjust name size in related data types")
>>
>> Signed-off-by: Andrew Rybchenko
>
> Reviewed-by: David Marchand
>
> Good catch, I guess we can clean ring too, quick grep:
>
> lib/ring/rte_ring_core.h-struct rte_ring {
> lib/ring/rte_ring_core.h- /*
> lib/ring/rte_ring_core.h:* Note: this field kept the
> RTE_MEMZONE_NAMESIZE size due to ABI
> lib/ring/rte_ring_core.h-* compatibility requirements, it
> could be changed to RTE_RING_NAMESIZE
> lib/ring/rte_ring_core.h:* next time the ABI changes
> lib/ring/rte_ring_core.h-*/
> lib/ring/rte_ring_core.h- char name[RTE_MEMZONE_NAMESIZE]
> __rte_cache_aligned;
>
>
Yes. I've not bothered to grep... Cc maintainers.
@David, @Konstantin, or @Honnappa, will you send a patch or
should I do?
Re: [dpdk-dev] [PATCH 2/3] ethdev: add flow item/action templates
Hi,
On 13/10/2021 04:25, Alexander Kozyrev wrote:
From: Ivan Malov On Wednesday, October 6, 2021 13:25
On 06/10/2021 07:48, Alexander Kozyrev wrote:
Treating every single flow rule as a completely independent and separate
entity negatively impacts the flow rules insertion rate. Oftentimes in an
application, many flow rules share a common structure (the same item
mask
and/or action list) so they can be grouped and classified together.
This knowledge may be used as a source of optimization by a PMD/HW.
The item template defines common matching fields (the item mask)
without
values. The action template holds a list of action types that will be used
together in the same rule. The specific values for items and actions will
be given only during the rule creation.
A table combines item and action templates along with shared flow rule
attributes (group ID, priority and traffic direction). This way a PMD/HW
can prepare all the resources needed for efficient flow rules creation in
the datapath. To avoid any hiccups due to memory reallocation, the
maximum
number of flow rules is defined at table creation time.
The flow rule creation is done by selecting a table, an item template
and an action template (which are bound to the table), and setting unique
values for the items and actions.
Signed-off-by: Alexander Kozyrev
Suggested-by: Ori Kam
---
lib/ethdev/rte_flow.h | 268
++
1 file changed, 268 insertions(+)
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index c69d503b90..ba3204b17e 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -4358,6 +4358,274 @@ int
rte_flow_configure(uint16_t port_id,
const struct rte_flow_port_attr *port_attr,
struct rte_flow_error *error);
+
+/**
+ * Opaque type returned after successfull creation of item template.
Typo: "successfull" --> "successful".
Thanks for noticing, will correct.
+ * This handle can be used to manage the created item template.
+ */
+struct rte_flow_item_template;
+
+__extension__
+struct rte_flow_item_template_attr {
+ /**
+* Version of the struct layout, should be 0.
+*/
+ uint32_t version;
+ /* No attributes so far. */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Create item template.
+ * The item template defines common matching fields (item mask)
without values.
+ * For example, matching on 5 tuple TCP flow, the template will be
+ * eth(null) + IPv4(source + dest) + TCP(s_port + d_port),
+ * while values for each rule will be set during the flow rule creation.
+ * The order of items in the template must be the same at rule insertion.
+ *
+ * @param port_id
+ * Port identifier of Ethernet device.
+ * @param[in] attr
+ * Item template attributes.
Please consider adding meaningful prefixes to "attr" here and below.
This is needed to avoid confusion with "struct rte_flow_attr".
Example: "template_attr".
No problem.
+ * @param[in] items
+ * Pattern specification (list terminated by the END pattern item).
+ * The spec member of an item is not used unless the end member is
used.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ * PMDs initialize this structure in case of error only.
+ *
+ * @return
+ * Handle on success, NULL otherwise and rte_errno is set.
+ */
+__rte_experimental
+struct rte_flow_item_template *
+rte_flow_item_template_create(uint16_t port_id,
+ const struct rte_flow_item_template_attr *attr,
+ const struct rte_flow_item items[],
+ struct rte_flow_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Destroy item template.
+ * This function may be called only when
+ * there are no more tables referencing this template.
+ *
+ * @param port_id
+ * Port identifier of Ethernet device.
+ * @param[in] template
+ * Handle to the template to be destroyed.
Perhaps "handle OF the template"?
You are right.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ * PMDs initialize this structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+__rte_experimental
+int
+rte_flow_item_template_destroy(uint16_t port_id,
+ struct rte_flow_item_template *template,
+ struct rte_flow_error *error);
+
+/**
+ * Opaque type returned after successfull creation of action template.
Single "l" in "successful".
Ditto.
+ * This handle can be used to manage the created action template.
+ */
+struct rte_flow_action_template;
+
+__extension__
+struct rte_flow_action_template_attr {
+ /**
+* Version of the struct layout, should be 0.
+*/
+ uint32_t version;
+ /* No attributes so far. */
+};
+
Re: [dpdk-dev] [PATCH v5] ethdev: replace bit shifts with macros
On 10/13/2021 8:52 AM, Thomas Monjalon wrote:
The macros RTE_BIT32 and RTE_BIT64 are used to replace bit shifts.
The macro UINT64C is also used to replace remaining occurrences of ULL.
The bit shifts of ETH_RSS_LEVEL_* are kept for aesthetic reason.
The API of rte_mtr and rte_tm is using enums for 64-bit variables.
As they are enums, unsigned bit cannot be used.
Signed-off-by: Thomas Monjalon
Reviewed-by: Andrew Rybchenko
---
v2: use RTE_BIT32 in enums
v3: rebase on main
v4: keep enums untouched
v5: convert new flag ETH_RSS_L4_CHKSUM
Hi Thomas,
Thanks for the update, but a recent commit [1] in ethdev is added a few
more '<<', can you please rebase on the latest next-net.
[1]
Commit c4f4884b654b ("ethdev: negotiate delivery of packet metadata from HW to
PMD")
Re: [dpdk-dev] [PATCH v1 1/1] ci: enable DPDK GHA for arm64 with self-hosted runners
On 10/13/21 4:03 AM, Serena He wrote:
CI jobs are triggered only for repos installed with given GHApp and runners
Cc: sta...@dpdk.org
Signed-off-by: Serena He
---
.github/workflows/build-arm64.yml | 118 ++
1 file changed, 118 insertions(+)
create mode 100644 .github/workflows/build-arm64.yml
diff --git a/.github/workflows/build-arm64.yml
b/.github/workflows/build-arm64.yml
new file mode 100644
index 00..570563f7c8
--- /dev/null
+++ b/.github/workflows/build-arm64.yml
Adding a new workflow should work on our 0-day-bot. We now support
having multiple workflows so this looks good
@@ -0,0 +1,118 @@
+name: build-arm64
+
+on:
+ push:
+ schedule:
+- cron: '0 0 * * 1'
nit: Please add a comment for when this is scheduled so we dont have to
do cron math :)
+
+defaults:
+ run:
+shell: bash --noprofile --norc -exo pipefail {0}
+
+jobs:
+ build:
+# Here, runners for arm64 are accessed by installed GitHub APP, thus will
not be available by fork.
+# you can change the following 'if' and 'runs-on' if you have your own
runners installed.
+# or request to get your repo on the whitelist to use GitHub APP and
delete this 'if'.
I think I understand. I think you mean s/GitHub APP/GitHub/ . otherwise
I dont know what that is. From my understanding you had to request
special arm-based runners from github
Are DPDK/dpdk and ovsrobot/dpdk whitelisted to use the arm-based runners?
Maybe there was a thread about this in the past that I missed, but where
and how do you get these arm-based runners from github?
+if: ${{ github.repository == 'DPDK/dpdk' || github.repository ==
'ovsrobot/dpdk' }}
+name: ${{ join(matrix.config.*, '-') }}
+runs-on: ${{ matrix.config.os }}
+env:
+ ABI_CHECKS: ${{ contains(matrix.config.checks, 'abi') }}
+ BUILD_DOCS: ${{ contains(matrix.config.checks, 'doc') }}
+ CL: ${{ matrix.config.compiler == 'clang' }}
+ CC: ccache ${{ matrix.config.compiler }}
+ DEF_LIB: ${{ matrix.config.library }}
+ LIBABIGAIL_VERSION: libabigail-1.8
+ REF_GIT_TAG: none
+
+strategy:
+ fail-fast: false
+ matrix:
+config:
+ - os: [self-hosted,arm-ubuntu-20.04]
+compiler: gcc
+library: static
+ - os: [self-hosted,arm-ubuntu-20.04]
+compiler: gcc
+library: shared
+checks: doc+tests
+ - os: [self-hosted,arm-ubuntu-20.04]
+compiler: clang
+library: static
+ - os: [self-hosted,arm-ubuntu-20.04]
+compiler: clang
+library: shared
+checks: doc+tests
+
+steps:
+- name: Checkout sources
+ uses: actions/checkout@v2
+- name: Generate cache keys
+ id: get_ref_keys
+ run: |
+echo -n '::set-output name=ccache::'
+echo 'ccache-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{
matrix.config.cross }}-'$(date -u +%Y-w%W)
+echo -n '::set-output name=libabigail::'
+echo 'libabigail-${{ matrix.config.os }}'
+echo -n '::set-output name=abi::'
+echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{
matrix.config.cross }}-${{ env.LIBABIGAIL_VERSION }}-${{ env.REF_GIT_TAG }}'
+- name: Retrieve ccache cache
+ uses: actions/cache@v2
+ with:
+path: ~/.ccache
+key: ${{ steps.get_ref_keys.outputs.ccache }}-${{ github.ref }}
+restore-keys: |
+ ${{ steps.get_ref_keys.outputs.ccache }}-refs/heads/main
+- name: Retrieve libabigail cache
+ id: libabigail-cache
+ uses: actions/cache@v2
+ if: env.ABI_CHECKS == 'true'
+ with:
+path: libabigail
+key: ${{ steps.get_ref_keys.outputs.libabigail }}
+- name: Retrieve ABI reference cache
+ uses: actions/cache@v2
+ if: env.ABI_CHECKS == 'true'
+ with:
+path: reference
+key: ${{ steps.get_ref_keys.outputs.abi }}
+- name: Update APT cache
+ run: sudo apt update || true
+- name: Install packages
+ run: sudo apt install -y ccache libnuma-dev python3-setuptools
+python3-wheel python3-pip python3-pyelftools ninja-build libbsd-dev
+libpcap-dev libibverbs-dev libcrypto++-dev libfdt-dev libjansson-dev
+libarchive-dev zlib1g-dev pkgconf
+- name: Install libabigail build dependencies if no cache is available
+ if: env.ABI_CHECKS == 'true' && steps.libabigail-cache.outputs.cache-hit
!= 'true'
+ run: sudo apt install -y autoconf automake libtool pkg-config libxml2-dev
+ libdw-dev
Lots of caching stuff. All of it needed?
+
+- name: Install test tools packages
+ run: sudo apt install -y gdb
+- name: Install doc generation packages
+ if: env.BUILD_DOCS == 'true'
+ run: sudo apt install -y doxygen graphviz python3-sphinx
+python3-sphinx-rtd-theme
+- name: Run setup
+ run: |
+.ci/linux-setup.sh
+#
Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
On 13/10/2021 12:11, Bruce Richardson wrote: > On Wed, Oct 13, 2021 at 11:02:02AM +0100, Kinsella, Ray wrote: >> >> >> On 13/10/2021 10:49, Thomas Monjalon wrote: >>> 13/10/2021 11:43, Kinsella, Ray: On 13/10/2021 10:40, Thomas Monjalon wrote: > 13/10/2021 10:51, Kinsella, Ray: >> On 12/10/2021 22:52, Thomas Monjalon wrote: >>> 12/10/2021 22:34, Dumitrescu, Cristian: From: Thomas Monjalon > 01/09/2021 14:20, Jasvinder Singh: >> These APIs were introduced in 18.05, therefore removing >> experimental tag to promote them to stable state. >> >> Signed-off-by: Jasvinder Singh >> --- >> lib/pipeline/rte_port_in_action.h | 10 -- >> lib/pipeline/rte_table_action.h | 18 -- >> lib/pipeline/version.map | 16 ++-- >> 3 files changed, 6 insertions(+), 38 deletions(-) > > Cristian, please can you check whether you intend to keep these > functions in > future? > If they are candidate to be removed, there is no point to promote > them. Hi Thomas, Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves. But removing them requires updating the drivers/net/softnic code to use the new API, which is not going to be completed in time for release 21.11. So given this lag, it might be better to simply promote these functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11. So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach. >>> >>> I think we should not promote API that we know will disappear soon. >>> The stable status means something for the users. >>> Ray, what is your opinion? >>> >> >> Well - I agree with Cristian (he and I discuss this a few weeks ago). >> My position is if you are going to maintain an API, that means giving a >> few guarantees. >> The API's have been experimental for 3 years ... at what point do they >> mature? >> >> However, I agree there is two ways to look at this thing, I try to be >> pragmatic. >> Maturing of any ABI/API is a conversation between a maintainer and the >> contributor. >> If they strongly feel, it is a pointless exercise - I won't argue. > > I think you did't get it. > This API will be removed soon. > That's why I think it doesn't make sense to make them stable, just before > removing. > Nope, I got it 110% I reflected both my opinion as ABI Maintainer, and tried to be pragmatic about the situation. As I said "Maturing of any ABI/API is a conversation between a maintainer and the contributor. If they strongly feel, it is a pointless exercise - I won't argue." >>> >>> Sorry, I don't understand your position. >>> Do you think we should promote functions to stable which are candidate to >>> be removed soon? >>> >> >> I am just reflecting the policy here. >> >> "An API’s experimental status should be reviewed annually, by both the >> maintainer and/or the original contributor. Ordinarily APIs marked as >> experimental will be promoted to the stable ABI once a maintainer has become >> satisfied that the API is mature and is unlikely to change." >> > If an API is planned for removal, then I think it falls under the bucket of > "likely to change", so should not be made non-experimental. Therefore I'd > agree with Thomas view on this - not so much that promoting them is > pointless, but I'd actually view it as harmful in encouraging use that will > be broken in future. > To be clear (again). I don't think we should promote functions needlessly, as I said, if others decide it is pointless, I won't argue. I do think if we have a policy, that experimental symbols will mature or be removed, we should be careful about the exceptions we make, lest the policy becomes irrelevant and ignored. Since we have argued this out, endlessly ... we can agree, we have been careful about this exception and move on? Ray K
[dpdk-dev] [V2] app/flow-perf: add destination ports parameter
Add optional destination ports parameter for port-id action.
The parameter is not must, and the value is 1 by default as before
if the parameter not provided.
For example:
$ dpdk-test-flow-perf -w 08:00.0,representor=[0,1] -- --transfer \
> --ingress --transfer --ether --portmask=0x2 --vxlan-encap \
> --port-id=0
This command means the rule created on representor 0 with port 0
as destination, since the portmask is 0x2 and dst-ports is 0:
$ dpdk-test-flow-perf -w 08:00.0,representor=[0,1] \
> -w 08:00.1,representor=[0,1]-- --transfer --ingress --transfer \
> --ether --portmask=0x12 --vxlan-encap --port-id=0,3
This command means the rules created on both representor 0 of PF 0
and PF 1, the destination port for the first represontor is PF 0,
and the destination port for the other one it PF 1.
Signed-off-by: Sean Zhang
---
v2:
remove new added dst-ports parameter, reuse port-id with optional
parameter
---
---
app/test-flow-perf/actions_gen.c | 7 +--
app/test-flow-perf/actions_gen.h | 2 +-
app/test-flow-perf/flow_gen.c| 3 ++-
app/test-flow-perf/flow_gen.h| 1 +
app/test-flow-perf/main.c| 29 +++--
doc/guides/tools/flow-perf.rst | 3 +++
6 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/app/test-flow-perf/actions_gen.c b/app/test-flow-perf/actions_gen.c
index 82cddfc676..8786dc967c 100644
--- a/app/test-flow-perf/actions_gen.c
+++ b/app/test-flow-perf/actions_gen.c
@@ -29,6 +29,7 @@ struct additional_para {
uint32_t counter;
uint64_t encap_data;
uint64_t decap_data;
+ uint16_t dst_port;
uint8_t core_idx;
bool unique_data;
};
@@ -171,12 +172,13 @@ add_set_tag(struct rte_flow_action *actions,
static void
add_port_id(struct rte_flow_action *actions,
uint8_t actions_counter,
- __rte_unused struct additional_para para)
+ struct additional_para para)
{
static struct rte_flow_action_port_id port_id = {
.id = PORT_ID_DST,
};
+ port_id.id = para.dst_port;
actions[actions_counter].type = RTE_FLOW_ACTION_TYPE_PORT_ID;
actions[actions_counter].conf = &port_id;
}
@@ -909,7 +911,7 @@ void
fill_actions(struct rte_flow_action *actions, uint64_t *flow_actions,
uint32_t counter, uint16_t next_table, uint16_t hairpinq,
uint64_t encap_data, uint64_t decap_data, uint8_t core_idx,
- bool unique_data)
+ bool unique_data, uint16_t dst_port)
{
struct additional_para additional_para_data;
uint8_t actions_counter = 0;
@@ -933,6 +935,7 @@ fill_actions(struct rte_flow_action *actions, uint64_t
*flow_actions,
.decap_data = decap_data,
.core_idx = core_idx,
.unique_data = unique_data,
+ .dst_port = dst_port,
};
if (hairpinq != 0) {
diff --git a/app/test-flow-perf/actions_gen.h b/app/test-flow-perf/actions_gen.h
index 6f2f833496..f3bb6fec41 100644
--- a/app/test-flow-perf/actions_gen.h
+++ b/app/test-flow-perf/actions_gen.h
@@ -20,6 +20,6 @@
void fill_actions(struct rte_flow_action *actions, uint64_t *flow_actions,
uint32_t counter, uint16_t next_table, uint16_t hairpinq,
uint64_t encap_data, uint64_t decap_data, uint8_t core_idx,
- bool unique_data);
+ bool unique_data, uint16_t dst_port);
#endif /* FLOW_PERF_ACTION_GEN */
diff --git a/app/test-flow-perf/flow_gen.c b/app/test-flow-perf/flow_gen.c
index 8f87fac5f6..890387bffa 100644
--- a/app/test-flow-perf/flow_gen.c
+++ b/app/test-flow-perf/flow_gen.c
@@ -45,6 +45,7 @@ generate_flow(uint16_t port_id,
uint16_t hairpinq,
uint64_t encap_data,
uint64_t decap_data,
+ uint16_t dst_port,
uint8_t core_idx,
bool unique_data,
struct rte_flow_error *error)
@@ -63,7 +64,7 @@ generate_flow(uint16_t port_id,
fill_actions(actions, flow_actions,
outer_ip_src, next_table, hairpinq,
encap_data, decap_data, core_idx,
- unique_data);
+ unique_data, dst_port);
fill_items(items, flow_items, outer_ip_src, core_idx);
diff --git a/app/test-flow-perf/flow_gen.h b/app/test-flow-perf/flow_gen.h
index dc887fceae..2daebbe493 100644
--- a/app/test-flow-perf/flow_gen.h
+++ b/app/test-flow-perf/flow_gen.h
@@ -34,6 +34,7 @@ generate_flow(uint16_t port_id,
uint16_t hairpinq,
uint64_t encap_data,
uint64_t decap_data,
+ uint16_t dst_port,
uint8_t core_idx,
bool unique_data,
struct rte_flow_error *error);
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 9be8edc31d..5d12bfeb03 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -56,6 +56,7 @@ static uint64_t flow_attrs[MAX_ATTRS_NUM];
static uint8_t items_idx, actions_idx, attrs_idx;
static uint64_t ports_mask;
+static uint16_t dst_ports[RTE_MAX_ETHPORTS];
static volatile bool force_quit;
Re: [dpdk-dev] [PATCH v3 00/12] ethdev: rework transfer flow API
On 10/10/2021 3:39 PM, Ivan Malov wrote: As per RFC [1], action PORT_ID appears to be ambiguous. Its name suggests that matching traffic be sent to the ethdev with the specified ID, that is, to the application. However, in Open vSwitch, the action is used to send traffic to a remote entity represented by the given port, that is, in the opposite direction. Its interpretation across PMDs also varies. RFC [2] attempted to define action PORT_ID semantics in vSwitch sense. However, this solution would completely abandon the opposite meaning. One more effort, RFC [3], was meant to declare that the use of direction attributes in "transfer" flows assumed implicit filtering by the port ID appearing as the first argument in rte_flow_create(). However, not all PMDs require such filtering, so the RFC turned out rather disputable. Since then, all of that has been given more thought: 1. One should not attempt to fix action PORT_ID. Instead, two new actions should be introduced. The first one should send traffic to the given ethdev. The second one should send it to the represented entity. 2. Similar to (1), two new items should be defined. The first one should match traffic going down from the given ethdev. The second one should match traffic going up from the entity represented by that ethdev. 3. The application always knows which packets come through which ethdevs. So, as per (2), the application can use the new item to match traffic arriving from precise entities represented by the relevant ethdev IDs. 4. New items suggested in (2) do not require the use of direction attributes. These items define precise directions on their own. 5. As a consequence of (3) and (4), the problem of implicit filtering by rte_flow_create() port ID argument and direction attributes is no longer a blocker. The new items allow to dispose of it. The new items appear to be symmetrical to each other. So do the new actions. This requires that their names reflect the symmetry. Also, the names should respect the existing concept of port representors. By the looks of it, terms "PORT_REPRESENTOR" and "REPRESENTED_PORT" satisfy these requirements. However, currently, ethdevs associated with network ports are not considered as their representors. Such understanding is mentioned in the documentation, but it's not expressed in the code (see enum rte_eth_representor_type). The short of it, this patch series follows points (1-5) to rework support for "transfer" flows accordingly. On the way, a string of ambiguous pattern items (PF, VF, PHY_PORT) is deprecated. The patch series also updates PMDs which support item and action PORT_ID to add support for replacements (1-2). However, there're some exceptions: - Support for traffic source items in the case of net/mlx5 is really complicated. This series does not rework it. The PMD maintainer can do the job much better and test the new code accordingly; - Support for action REPRESENTED_PORT is not added to net/sfc. This will be done when support for VF representors has been upstreamed, just for the new code to apply cleanly. Changes in v2: * New naming and reworked comments * New diagrams Changes in v3: * Diagram improvements * Spelling fixes [1] https://patches.dpdk.org/project/dpdk/patch/20210907125157.3843-1-ivan.ma...@oktetlabs.ru/ [2] https://patches.dpdk.org/project/dpdk/patch/20210903074610.313622-1-andrew.rybche...@oktetlabs.ru/ [3] https://patches.dpdk.org/project/dpdk/patch/20210901151104.3923889-1-andrew.rybche...@oktetlabs.ru/ Andrew Rybchenko (6): net/bnxt: support meta flow items to match on traffic source net/bnxt: support meta flow actions to overrule destinations net/enic: support meta flow actions to overrule destinations net/mlx5: support represented port flow action net/octeontx2: support port representor flow action net/sfc: support port representor flow item Ivan Malov (6): ethdev: add port representor item to flow API ethdev: add represented port item to flow API ethdev: add port representor action to flow API ethdev: add represented port action to flow API ethdev: deprecate hard-to-use or ambiguous items and actions ethdev: deprecate direction attributes in transfer flows The rte flow documentation script is failing [1], should new actions added to the documentation? [1] ./devtools/check-doc-vs-code.sh rte_flow doc out of sync for bnxt item port_representor item represented_port action port_representor action represented_port rte_flow doc out of sync for enic action port_representor action represented_port rte_flow doc out of sync for mlx5 action represented_port rte_flow doc out of sync for octeontx2 action port_representor rte_flow doc out of sync for sfc item port_representor
Re: [dpdk-dev] [PATCH v3 01/12] ethdev: add port representor item to flow API
On 10/10/2021 3:39 PM, Ivan Malov wrote: diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst index 89d4b33ef1..1261cb2bf3 100644 --- a/doc/guides/rel_notes/release_21_11.rst +++ b/doc/guides/rel_notes/release_21_11.rst @@ -188,6 +188,8 @@ API Changes Also, make sure to start the actual text at the margin. === +* ethdev: Added item ``PORT_REPRESENTOR`` to flow API. + Since there will be a new version, can you please add 'ethdev' update after core libraries, for existing doc it is after 'cryptodev' changes?
Re: [dpdk-dev] [PATCH v4 0/6] ethdev: introduce shared Rx queue
On Tue, 2021-10-12 at 14:28 +0300, Andrew Rybchenko wrote: > On 10/12/21 1:55 PM, Xueming(Steven) Li wrote: > > On Tue, 2021-10-12 at 11:48 +0300, Andrew Rybchenko wrote: > > > On 10/12/21 9:37 AM, Xueming(Steven) Li wrote: > > > > On Mon, 2021-10-11 at 23:11 +0800, Xueming Li wrote: > > > > > On Mon, 2021-10-11 at 14:49 +0300, Andrew Rybchenko wrote: > > > > > > Hi Xueming, > > > > > > > > > > > > On 9/30/21 5:55 PM, Xueming Li wrote: > > > > > > > In current DPDK framework, all RX queues is pre-loaded with mbufs > > > > > > > for > > > > > > > incoming packets. When number of representors scale out in a > > > > > > > switch > > > > > > > domain, the memory consumption became significant. Further more, > > > > > > > polling all ports leads to high cache miss, high latency and low > > > > > > > throughputs. > > > > > > > > > > > > > > This patch introduces shared RX queue. PF and representors with > > > > > > > same > > > > > > > configuration in same switch domain could share RX queue set by > > > > > > > specifying shared Rx queue offloading flag and sharing group. > > > > > > > > > > > > > > All ports that Shared Rx queue actually shares One Rx queue and > > > > > > > only > > > > > > > pre-load mbufs to one Rx queue, memory is saved. > > > > > > > > > > > > > > Polling any queue using same shared RX queue receives packets > > > > > > > from all > > > > > > > member ports. Source port is identified by mbuf->port. > > > > > > > > > > > > > > Multiple groups is supported by group ID. Port queue number in a > > > > > > > shared > > > > > > > group should be identical. Queue index is 1:1 mapped in shared > > > > > > > group. > > > > > > > An example of polling two share groups: > > > > > > > coregroup queue > > > > > > > 0 0 0 > > > > > > > 1 0 1 > > > > > > > 2 0 2 > > > > > > > 3 0 3 > > > > > > > 4 1 0 > > > > > > > 5 1 1 > > > > > > > 6 1 2 > > > > > > > 7 1 3 > > > > > > > > > > > > > > Shared RX queue must be polled on single thread or core. If both > > > > > > > PF0 and > > > > > > > representor0 joined same share group, can't poll pf0rxq0 on core1 > > > > > > > and > > > > > > > rep0rxq0 on core2. Actually, polling one port within share group > > > > > > > is > > > > > > > sufficient since polling any port in group will return packets > > > > > > > for any > > > > > > > port in group. > > > > > > > > > > > > I apologize that I jump in into the review process that late. > > > > > > > > > > Appreciate the bold suggestion, never too late :) > > > > > > > > > > > > > > > > > Frankly speaking I doubt that it is the best design to solve > > > > > > the problem. Yes, I confirm that the problem exists, but I > > > > > > think there is better and simpler way to solve it. > > > > > > > > > > > > The problem of the suggested solution is that it puts all > > > > > > the headache about consistency to application and PMDs > > > > > > without any help from ethdev layer to guarantee the > > > > > > consistency. As the result I believe it will be either > > > > > > missing/lost consistency checks or huge duplication in > > > > > > each PMD which supports the feature. Shared RxQs must be > > > > > > equally configured including number of queues, offloads > > > > > > (taking device level Rx offloads into account), RSS > > > > > > settings etc. So, applications must care about it and > > > > > > PMDs (or ethdev layer) must check it. > > > > > > > > > > The name might be confusing, here is my understanding: > > > > > 1. NIC shares the buffer supply HW Q between shared RxQs - for memory > > > > > 2. PMD polls one shared RxQ - for latency and performance > > > > > 3. Most per queue features like offloads and RSS not impacted. That's > > > > > why this not mentioned. Some offloading might not being supported due > > > > > to PMD or hw limitation, need to add check in PMD case by case. > > > > > 4. Multiple group is defined for service level flexibility. For > > > > > example, PF and VIP customer's load distributed via queues and > > > > > dedicate > > > > > cores. Low priority customers share one core with one shared queue. > > > > > multiple groups enables more combination. > > > > > 5. One port could assign queues to different group for polling > > > > > flexibility. For example first 4 queues in group 0 and next 4 queues > > > > > in > > > > > group1, each group have other member ports with 4 queues, so the port > > > > > with 8 queues could be polled with 8 cores w/o non-shared rxq penalty, > > > > > in other words, each core only poll one shared RxQ. > > > > > > > > > > > > > > > > > The advantage of the solution is that any device may > > > > > > create group and subsequent devices join. Absence of > > > > > > primary device is nice. But do we really need it? > > > > > > Will the design work if some representors are configured > > > > > > to use shared RxQ, but some do n
Re: [dpdk-dev] [PATCH v3 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions
On 10/10/2021 3:39 PM, Ivan Malov wrote: --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -122,12 +122,6 @@ Deprecation Notices is deprecated and will be removed in DPDK 21.11. Shared counters should be managed using shared actions API (``rte_flow_shared_action_create`` etc). -* ethdev: Definition of the flow API action ``RTE_FLOW_ACTION_TYPE_PORT_ID`` - is ambiguous and needs clarification. - Structure ``rte_flow_action_port_id`` will be extended to specify - traffic direction to the represented entity or ethdev port itself - in DPDK 21.11. - * ethdev: Flow API documentation is unclear if ethdev port used to create a flow rule adds any implicit match criteria in the case of transfer rules. The semantics will be clarified in DPDK 21.11 and it will require fixes in @@ -256,3 +250,6 @@ Deprecation Notices * cmdline: ``cmdline`` structure will be made opaque to hide platform-specific content. On Linux and FreeBSD, supported prior to DPDK 20.11, original structure will be kept until DPDK 21.11. + +* ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are + deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11. Since there will be a new version, can you please add new 'ethdev' deprecation notices, to the end of the 'ethdev' related deprecation notice group above?
Re: [dpdk-dev] [dpdk-stable] [Patch v2] bus/vmbus: map to the correct ring buffer addresses for the secondary process
29/09/2021 22:46, lon...@linuxonhyperv.com:
> From: Long Li
>
> The driver code had wrong assumption that all the addresses to ring buffers
> in the secondary process are the same as those in the primary process. This
> is not always correct as the channels could be mapped to different
> addresses in the secondary process.
>
> Fix this by keeping track of all the mapped addresses from the primary
> process in the shared uio_res, and have second process map to the same
> addresses.
>
> Fixes: 831dba47bd36 ("bus/vmbus: add Hyper-V virtual bus support")
>
> Reported-by: Jonathan Erb
> Cc: sta...@dpdk.org
> Signed-off-by: Long Li
You forgot this ack from v1:
Acked-by: Stephen Hemminger
Applied, thanks
Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
13/10/2021 13:42, Kinsella, Ray: > On 13/10/2021 12:11, Bruce Richardson wrote: > > On Wed, Oct 13, 2021 at 11:02:02AM +0100, Kinsella, Ray wrote: > >> On 13/10/2021 10:49, Thomas Monjalon wrote: > >>> 13/10/2021 11:43, Kinsella, Ray: > On 13/10/2021 10:40, Thomas Monjalon wrote: > > 13/10/2021 10:51, Kinsella, Ray: > >> On 12/10/2021 22:52, Thomas Monjalon wrote: > >>> 12/10/2021 22:34, Dumitrescu, Cristian: > From: Thomas Monjalon > > 01/09/2021 14:20, Jasvinder Singh: > >> These APIs were introduced in 18.05, therefore removing > >> experimental tag to promote them to stable state. > >> > >> Signed-off-by: Jasvinder Singh > >> --- > >> lib/pipeline/rte_port_in_action.h | 10 -- > >> lib/pipeline/rte_table_action.h | 18 -- > >> lib/pipeline/version.map | 16 ++-- > >> 3 files changed, 6 insertions(+), 38 deletions(-) > > > > Cristian, please can you check whether you intend to keep these > > functions in > > future? > > If they are candidate to be removed, there is no point to promote > > them. > > Hi Thomas, > > Yes, they are candidate for removal, as the new rte_swx_pipeline API > evolves. > > But removing them requires updating the drivers/net/softnic code to > use the new API, which is not going to be completed in time for > release 21.11. > > So given this lag, it might be better to simply promote these > functions to stable API now, as Ray suggests, instead of continuing > to keep them experimental; then, once these functions are no longer > used, then we can remove them, most likely in 22.11. > > So I will ack these patches, but I am willing to reconsider if you > feel strongly against this approach. > >>> > >>> I think we should not promote API that we know will disappear soon. > >>> The stable status means something for the users. > >>> Ray, what is your opinion? > >>> > >> > >> Well - I agree with Cristian (he and I discuss this a few weeks ago). > >> My position is if you are going to maintain an API, that means giving > >> a few guarantees. > >> The API's have been experimental for 3 years ... at what point do they > >> mature? > >> > >> However, I agree there is two ways to look at this thing, I try to be > >> pragmatic. > >> Maturing of any ABI/API is a conversation between a maintainer and the > >> contributor. > >> If they strongly feel, it is a pointless exercise - I won't argue. > > > > I think you did't get it. > > This API will be removed soon. > > That's why I think it doesn't make sense to make them stable, just > > before removing. > > > > Nope, I got it 110% > I reflected both my opinion as ABI Maintainer, and tried to be pragmatic > about the situation. > > As I said "Maturing of any ABI/API is a conversation between a > maintainer and the contributor. > If they strongly feel, it is a pointless exercise - I won't argue." > >>> > >>> Sorry, I don't understand your position. > >>> Do you think we should promote functions to stable which are candidate to > >>> be removed soon? > >>> > >> > >> I am just reflecting the policy here. > >> > >> "An API’s experimental status should be reviewed annually, by both the > >> maintainer and/or the original contributor. Ordinarily APIs marked as > >> experimental will be promoted to the stable ABI once a maintainer has > >> become satisfied that the API is mature and is unlikely to change." > >> > > If an API is planned for removal, then I think it falls under the bucket of > > "likely to change", so should not be made non-experimental. Therefore I'd > > agree with Thomas view on this - not so much that promoting them is > > pointless, but I'd actually view it as harmful in encouraging use that will > > be broken in future. > > > > To be clear (again). > > I don't think we should promote functions needlessly, as I said, if others > decide it is pointless, I won't argue. > I do think if we have a policy, that experimental symbols will mature or be > removed, we should be careful about the exceptions we make, lest the policy > becomes irrelevant and ignored. > > Since we have argued this out, endlessly ... we can agree, we have been > careful about this exception and move on? The patch is set as rejected.
Re: [dpdk-dev] [PATCH] net/hns3: fix incorrect free function
On 10/13/2021 9:09 AM, Min Hu (Connor) wrote:
From: Chengwen Feng
The intr_handle->intr_vec is allocated by rte_zmalloc(), but freed by
free(), this patch fixes it.
Fixes: 02a7b55657b2 ("net/hns3: support Rx interrupt")
Cc: sta...@dpdk.org
Signed-off-by: Chengwen Feng
Reviewed-by: Ferruh Yigit
Applied to dpdk-next-net/main, thanks.
Re: [dpdk-dev] [PATCH v4] eventdev/rx_adapter: add telemetry callbacks
Acked-by: Naga Harish K S V
> -Original Message-
> From: dev On Behalf Of Ganapati Kundapura
> Sent: Wednesday, October 13, 2021 1:27 PM
> To: jerinjac...@gmail.com; dev@dpdk.org
> Cc: Jayatheerthan, Jay
> Subject: [dpdk-dev] [PATCH v4] eventdev/rx_adapter: add telemetry
> callbacks
>
> Added telemetry callbacks to get Rx adapter stats, reset stats and to get Rx
> queue config information.
>
> Acked-by: Jay Jayatheerthan
>
> Signed-off-by: Ganapati Kundapura
> ---
> v4:
> * Addressed segfault when per Rx queue event buffer is used.
>
> v3:
> * Updated release notes.
> * Addressed review comments.
>
> v2:
> * Fixed checkpatch warning.
> ---
>
> diff --git a/doc/guides/rel_notes/release_21_11.rst
> b/doc/guides/rel_notes/release_21_11.rst
> index dfc2cbd..9955e52 100644
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -130,6 +130,10 @@ New Features
>* Added tests to validate packets hard expiry.
>* Added tests to verify tunnel header verification in IPsec inbound.
>
> +* **Updated rte_event_eth_rx_adapter_stats structure
> + * Added 'uint64_t rx_event_buf_count'
> + * Added 'uint64_t rx_event_buf_size'
> +
>
> Removed Items
> -
> diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
> b/lib/eventdev/rte_event_eth_rx_adapter.c
> index 9ac976c..bd68b8e 100644
> --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include "rte_eventdev.h"
> #include "eventdev_pmd.h"
> @@ -2852,6 +2853,7 @@ rte_event_eth_rx_adapter_stats_get(uint8_t id,
> struct rte_event_eth_rx_adapter_stats *stats) {
> struct rte_event_eth_rx_adapter *rx_adapter;
> + struct rte_eth_event_enqueue_buffer *buf;
> struct rte_event_eth_rx_adapter_stats dev_stats_sum = { 0 };
> struct rte_event_eth_rx_adapter_stats dev_stats;
> struct rte_eventdev *dev;
> @@ -2890,6 +2892,15 @@ rte_event_eth_rx_adapter_stats_get(uint8_t id,
> stats->rx_packets += dev_stats_sum.rx_packets;
> stats->rx_enq_count += dev_stats_sum.rx_enq_count;
>
> + if (!rx_adapter->use_queue_event_buf) {
> + buf = &rx_adapter->event_enqueue_buffer;
> + stats->rx_event_buf_count = buf->count;
> + stats->rx_event_buf_size = buf->events_size;
> + } else {
> + stats->rx_event_buf_count = 0;
> + stats->rx_event_buf_size = 0;
> + }
> +
> return 0;
> }
>
> @@ -3052,3 +3063,146 @@
> rte_event_eth_rx_adapter_queue_conf_get(uint8_t id,
>
> return 0;
> }
> +
> +#define RXA_ADD_DICT(stats, s) rte_tel_data_add_dict_u64(d, #s,
> +stats.s)
> +
> +static int
> +handle_rxa_stats(const char *cmd __rte_unused,
> + const char *params,
> + struct rte_tel_data *d)
> +{
> + uint8_t rx_adapter_id;
> + struct rte_event_eth_rx_adapter_stats rx_adptr_stats;
> +
> + if (params == NULL || strlen(params) == 0 || !isdigit(*params))
> + return -1;
> +
> + /* Get Rx adapter ID from parameter string */
> + rx_adapter_id = atoi(params);
> +
> RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(rx_adapter
> _id, -EINVAL);
> +
> + /* Get Rx adapter stats */
> + if (rte_event_eth_rx_adapter_stats_get(rx_adapter_id,
> +&rx_adptr_stats)) {
> + RTE_EDEV_LOG_ERR("Failed to get Rx adapter stats\n");
> + return -1;
> + }
> +
> + rte_tel_data_start_dict(d);
> + rte_tel_data_add_dict_u64(d, "rx_adapter_id", rx_adapter_id);
> + RXA_ADD_DICT(rx_adptr_stats, rx_packets);
> + RXA_ADD_DICT(rx_adptr_stats, rx_poll_count);
> + RXA_ADD_DICT(rx_adptr_stats, rx_dropped);
> + RXA_ADD_DICT(rx_adptr_stats, rx_enq_retry);
> + RXA_ADD_DICT(rx_adptr_stats, rx_event_buf_count);
> + RXA_ADD_DICT(rx_adptr_stats, rx_event_buf_size);
> + RXA_ADD_DICT(rx_adptr_stats, rx_enq_count);
> + RXA_ADD_DICT(rx_adptr_stats, rx_enq_start_ts);
> + RXA_ADD_DICT(rx_adptr_stats, rx_enq_block_cycles);
> + RXA_ADD_DICT(rx_adptr_stats, rx_enq_end_ts);
> + RXA_ADD_DICT(rx_adptr_stats, rx_intr_packets);
> +
> + return 0;
> +}
> +
> +static int
> +handle_rxa_stats_reset(const char *cmd __rte_unused,
> +const char *params,
> +struct rte_tel_data *d __rte_unused) {
> + uint8_t rx_adapter_id;
> +
> + if (params == NULL || strlen(params) == 0 || ~isdigit(*params))
> + return -1;
> +
> + /* Get Rx adapter ID from parameter string */
> + rx_adapter_id = atoi(params);
> +
> RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(rx_adapter
> _id, -EINVAL);
> +
> + /* Reset Rx adapter stats */
> + if (rte_event_eth_rx_adapter_stats_reset(rx_adapter_id)) {
> + RTE_EDEV_LOG_ERR("Failed to reset Rx adapter stats\n");
> + return -1;
Re: [dpdk-dev] [PATCH] port: eventdev port api promoted
+Cc Cristian, the maintainer 10/09/2021 15:40, Kinsella, Ray: > On 10/09/2021 08:36, David Marchand wrote: > > On Fri, Sep 10, 2021 at 9:31 AM Kinsella, Ray wrote: > >> On 09/09/2021 17:40, Rahul Shah wrote: > >>> rte_port_eventdev_reader_ops, rte_port_eventdev_writer_nodrops_ops, > >>> rte_port_eventdev_writer_ops symbols promoted > >>> > >>> Signed-off-by: Rahul Shah > >>> --- > >>> lib/port/version.map | 8 +++- > >>> 1 file changed, 3 insertions(+), 5 deletions(-) > >> > >> Hi Rahul, > >> > >> You need to strip the __rte_experimental attribute in the header file also. > > > > That's what I first thought... but those are variables, and there were > > not marked in the header. > > My mistake - should have checked. > > > At least, those symbols must be alphabetically sorted in version.map. > > > > About checking for experimental mark on variables... I had a patch, > > but never got it in. > > I think we should instead (forbid such exports and|insist on) rework > > API / libraries that rely on public variables. > > I'll pull together a script to identify all the variables in DPDK. > Are you expecting the rework on the port api to be done prior to 21.11? Does it mean we should not promote these variables?
Re: [dpdk-dev] [PATCH v5] net: introduce IPv4 ihl and version fields
On 10/12/2021 1:29 PM, Gregory Etelson wrote: RTE IPv4 header definition combines the `version' and `ihl' fields into a single structure member. This patch introduces dedicated structure members for both `version' and `ihl' IPv4 fields. Separated header fields definitions allow to create simplified code to match on the IHL value in a flow rule. The original `version_ihl' structure member is kept for backward compatibility. The patch implements one of 2 announced changes to the IPv4 header. IPv4 header encodes fragment information into 16 bits field. 3 bits hold flags and remaining 13 bits are for fragment offset. 13 bits bit-field cannot be defined both for big and little endian systems. Signed-off-by: Gregory Etelson Acked-by: Olivier Matz <...> --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -167,12 +167,6 @@ Deprecation Notices * net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets headers. -* net: The structure ``rte_ipv4_hdr`` will have two unions. - The first union is for existing ``version_ihl`` byte - and new bitfield for version and IHL. - The second union is for existing ``fragment_offset`` - and new bitfield for fragment flags and offset. - The deprecation notice for `fragment_offset` seems not implemented but removed. What do you think to remove the relevant part that is implemented in this patch, remove the residue in another patch explaining why it is not implemented?
Re: [dpdk-dev] [PATCH v8 06/10] ipsec: add transmit segmentation offload support
On 10/12/2021 5:25 PM, Ananyev, Konstantin wrote:
+/* check if packet will exceed MSS and segmentation is required */
+static inline int
+esn_outb_nb_segments(struct rte_mbuf *m) {
DPDK codying style pls.
+ uint16_t segments = 1;
+ uint16_t pkt_l3len = m->pkt_len - m->l2_len;
+
+ /* Only support segmentation for UDP/TCP flows */
+ if (!(m->packet_type & (RTE_PTYPE_L4_UDP | RTE_PTYPE_L4_TCP)))
For ptypes it is not a bit flag, it should be something like:
pt = m->packet_type & RTE_PTYPE_L4_MASK;
if (pt == RTE_PTYPE_L4_UDP || pt == RTE_PTYPE_L4_TCP) {...}
BTW, ptype is usually used for RX path.
If you expect user to setup it up on TX path - it has to be documented in
formal API comments.
Thinking a bit more about it:
Do we really need to force user to set ptypes to use this feature?
Might be something as simple as follows would work:
1. If user expects that he would need TSO for the ESP packet,
he would simply set PKT_TX_TCP_SEG flag and usual offload fields required
(l2_len, l3_len, l4_len, tso_segsz).
2. In ipsec lib we'll check for PKT_TX_TCP_SEG - and if it is set we'll do
extra processing
(as your patch does - calc number of segments, fill ESP data in a bit different
way,
fill outer_l2_len, outer_l3_len etc.)
3. If user overestimate things and there would be just one segment within
packet with
PKT_TX_TCP_SEG - I don't think it is a big deal, things will keep working
correctly and AFAIK
there would be no slowdown.
That way it should probably simplify things for this feature and would help
avoid setting extra ol_flags inside ipsec lib.
Yes, this sounds good, I will rework it like so.
One side question - how PMD will report that this feature is supported?
Would it be extra field in rte_security_ipsec_xform or something different?
The assumption is that if a PMD supports inline crypto and TSO it will
support them together, as DEV_TX_OFFLOAD_SECURITY | DEV_TX_OFFLOAD_TCP_TSO
[dpdk-dev] [PATCH v9 00/10] new features for ipsec and security libraries
Add support for: TSO, NAT-T/UDP encapsulation, ESN AES_CCM, CHACHA20_POLY1305 and AES_GMAC SA telemetry mbuf offload flags Initial SQN value Signed-off-by: Declan Doherty Signed-off-by: Radu Nicolau Signed-off-by: Abhijit Sinha Signed-off-by: Daniel Martin Buckley Radu Nicolau (10): security: add ESN field to ipsec_xform ipsec: add support for AEAD algorithms security: add UDP params for IPsec NAT-T ipsec: add support for NAT-T mbuf: add IPsec ESP tunnel type ipsec: add transmit segmentation offload support ipsec: add support for SA telemetry ipsec: add support for initial SQN value doc: remove unneeded ipsec new field deprecation doc: remove unneeded security deprecation doc/guides/prog_guide/ipsec_lib.rst| 14 +- doc/guides/rel_notes/deprecation.rst | 11 -- doc/guides/rel_notes/release_21_11.rst | 17 ++ lib/ipsec/crypto.h | 137 ++ lib/ipsec/esp_inb.c| 84 - lib/ipsec/esp_outb.c | 211 + lib/ipsec/ipsec_telemetry.c| 244 + lib/ipsec/meson.build | 6 +- lib/ipsec/rte_ipsec.h | 23 +++ lib/ipsec/rte_ipsec_sa.h | 9 +- lib/ipsec/sa.c | 119 ++-- lib/ipsec/sa.h | 15 ++ lib/ipsec/version.map | 9 + lib/mbuf/rte_mbuf_core.h | 1 + lib/security/rte_security.h| 15 ++ 15 files changed, 843 insertions(+), 72 deletions(-) create mode 100644 lib/ipsec/ipsec_telemetry.c -- v2: fixed lib/ipsec/version.map updates to show correct version v3: fixed build error and corrected misspelled email address v4: add doxygen comments for the IPsec telemetry APIs update inline comments refering to the wrong RFC v5: update commit messages after feedback update the UDP encapsulation patch to actually use the configured ports v6: fix initial SQN value v7: reworked the patches after feedback v8: updated library doc, release notes and removed deprecation notices v9: reworked telemetry, tso and esn patches 2.25.1
[dpdk-dev] [PATCH v9 01/10] security: add ESN field to ipsec_xform
Update ipsec_xform definition to include ESN field.
This allows the application to control the ESN starting value.
Signed-off-by: Declan Doherty
Signed-off-by: Radu Nicolau
Signed-off-by: Abhijit Sinha
Signed-off-by: Daniel Martin Buckley
Acked-by: Fan Zhang
Acked-by: Anoob Joseph
Acked-by: Konstantin Ananyev
---
doc/guides/rel_notes/deprecation.rst | 2 +-
doc/guides/rel_notes/release_21_11.rst | 5 +
lib/security/rte_security.h| 8
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index a4e86b31f5..accb9c7d83 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -206,7 +206,7 @@ Deprecation Notices
* security: The structure ``rte_security_ipsec_xform`` will be extended with
multiple fields: source and destination port of UDP encapsulation,
- IPsec payload MSS (Maximum Segment Size), and ESN (Extended Sequence Number).
+ IPsec payload MSS (Maximum Segment Size).
* security: The IPsec SA config options ``struct
rte_security_ipsec_sa_options``
will be updated with new fields to support new features like TSO in case of
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 54718ff367..f840586a20 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -265,6 +265,11 @@ ABI Changes
packet IPv4 header checksum and L4 checksum need to be offloaded to
security device.
+* security: A new structure ``esn`` was added in structure
+ ``rte_security_ipsec_xform`` to set an initial ESN value. This permits
+ application to start from an arbitrary ESN value for debug and SA lifetime
+ enforcement purposes.
+
* bbdev: Added capability related to more comprehensive CRC options,
shifting values of the ``enum rte_bbdev_op_ldpcdec_flag_bitmasks``.
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 7eb9f109ae..764ce83bca 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -318,6 +318,14 @@ struct rte_security_ipsec_xform {
/**< Anti replay window size to enable sequence replay attack handling.
* replay checking is disabled if the window size is 0.
*/
+ union {
+ uint64_t value;
+ struct {
+ uint32_t low;
+ uint32_t hi;
+ };
+ } esn;
+ /**< Extended Sequence Number */
};
/**
--
2.25.1
[dpdk-dev] [PATCH v9 02/10] ipsec: add support for AEAD algorithms
Add support for AES_CCM, CHACHA20_POLY1305 and AES_GMAC.
Signed-off-by: Declan Doherty
Signed-off-by: Radu Nicolau
Signed-off-by: Abhijit Sinha
Signed-off-by: Daniel Martin Buckley
Acked-by: Fan Zhang
Acked-by: Konstantin Ananyev
---
doc/guides/prog_guide/ipsec_lib.rst| 3 +-
doc/guides/rel_notes/release_21_11.rst | 4 +
lib/ipsec/crypto.h | 137 +
lib/ipsec/esp_inb.c| 66 +++-
lib/ipsec/esp_outb.c | 70 -
lib/ipsec/sa.c | 54 +-
lib/ipsec/sa.h | 6 ++
7 files changed, 328 insertions(+), 12 deletions(-)
diff --git a/doc/guides/prog_guide/ipsec_lib.rst
b/doc/guides/prog_guide/ipsec_lib.rst
index 9f2b26072d..93e213bf36 100644
--- a/doc/guides/prog_guide/ipsec_lib.rst
+++ b/doc/guides/prog_guide/ipsec_lib.rst
@@ -313,7 +313,8 @@ Supported features
* ESN and replay window.
-* algorithms: 3DES-CBC, AES-CBC, AES-CTR, AES-GCM, HMAC-SHA1, NULL.
+* algorithms: 3DES-CBC, AES-CBC, AES-CTR, AES-GCM, AES_CCM, CHACHA20_POLY1305,
+ AES_GMAC, HMAC-SHA1, NULL.
Limitations
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index f840586a20..544d44b1a8 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -154,6 +154,10 @@ New Features
* Added tests to verify tunnel header verification in IPsec inbound.
* Added tests to verify inner checksum.
+* **IPsec library new features.**
+
+ * Added support for AEAD algorithms AES_CCM, CHACHA20_POLY1305 and AES_GMAC.
+
Removed Items
-
diff --git a/lib/ipsec/crypto.h b/lib/ipsec/crypto.h
index 3d03034590..93d200 100644
--- a/lib/ipsec/crypto.h
+++ b/lib/ipsec/crypto.h
@@ -21,6 +21,37 @@ struct aesctr_cnt_blk {
uint32_t cnt;
} __rte_packed;
+ /*
+ * CHACHA20-POLY1305 devices have some specific requirements
+ * for IV and AAD formats.
+ * Ideally that to be done by the driver itself.
+ */
+
+struct aead_chacha20_poly1305_iv {
+ uint32_t salt;
+ uint64_t iv;
+ uint32_t cnt;
+} __rte_packed;
+
+struct aead_chacha20_poly1305_aad {
+ uint32_t spi;
+ /*
+* RFC 4106, section 5:
+* Two formats of the AAD are defined:
+* one for 32-bit sequence numbers, and one for 64-bit ESN.
+*/
+ union {
+ uint32_t u32[2];
+ uint64_t u64;
+ } sqn;
+ uint32_t align0; /* align to 16B boundary */
+} __rte_packed;
+
+struct chacha20_poly1305_esph_iv {
+ struct rte_esp_hdr esph;
+ uint64_t iv;
+} __rte_packed;
+
/*
* AES-GCM devices have some specific requirements for IV and AAD formats.
* Ideally that to be done by the driver itself.
@@ -51,6 +82,47 @@ struct gcm_esph_iv {
uint64_t iv;
} __rte_packed;
+ /*
+ * AES-CCM devices have some specific requirements for IV and AAD formats.
+ * Ideally that to be done by the driver itself.
+ */
+union aead_ccm_salt {
+ uint32_t salt;
+ struct inner {
+ uint8_t salt8[3];
+ uint8_t ccm_flags;
+ } inner;
+} __rte_packed;
+
+
+struct aead_ccm_iv {
+ uint8_t ccm_flags;
+ uint8_t salt[3];
+ uint64_t iv;
+ uint32_t cnt;
+} __rte_packed;
+
+struct aead_ccm_aad {
+ uint8_t padding[18];
+ uint32_t spi;
+ /*
+* RFC 4309, section 5:
+* Two formats of the AAD are defined:
+* one for 32-bit sequence numbers, and one for 64-bit ESN.
+*/
+ union {
+ uint32_t u32[2];
+ uint64_t u64;
+ } sqn;
+ uint32_t align0; /* align to 16B boundary */
+} __rte_packed;
+
+struct ccm_esph_iv {
+ struct rte_esp_hdr esph;
+ uint64_t iv;
+} __rte_packed;
+
+
static inline void
aes_ctr_cnt_blk_fill(struct aesctr_cnt_blk *ctr, uint64_t iv, uint32_t nonce)
{
@@ -59,6 +131,16 @@ aes_ctr_cnt_blk_fill(struct aesctr_cnt_blk *ctr, uint64_t
iv, uint32_t nonce)
ctr->cnt = rte_cpu_to_be_32(1);
}
+static inline void
+aead_chacha20_poly1305_iv_fill(struct aead_chacha20_poly1305_iv
+ *chacha20_poly1305,
+ uint64_t iv, uint32_t salt)
+{
+ chacha20_poly1305->salt = salt;
+ chacha20_poly1305->iv = iv;
+ chacha20_poly1305->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)
{
@@ -67,6 +149,21 @@ aead_gcm_iv_fill(struct aead_gcm_iv *gcm, uint64_t iv,
uint32_t salt)
gcm->cnt = rte_cpu_to_be_32(1);
}
+static inline void
+aead_ccm_iv_fill(struct aead_ccm_iv *ccm, uint64_t iv, uint32_t salt)
+{
+ union aead_ccm_salt tsalt;
+
+ tsalt.salt = salt;
+ ccm->ccm_flags = tsalt.inner.ccm_flags;
+ ccm->salt[0] = tsalt.inner.salt8[0];
+ ccm->salt[1] = tsalt.inner.salt8[1];
+ ccm->salt[2] = tsalt.in
[dpdk-dev] [PATCH v9 03/10] security: add UDP params for IPsec NAT-T
Add support for specifying UDP port params for UDP encapsulation option.
RFC3948 section-2.1 does not enforce using specific the UDP ports for
UDP-Encapsulated ESP Header
Signed-off-by: Declan Doherty
Signed-off-by: Radu Nicolau
Signed-off-by: Abhijit Sinha
Signed-off-by: Daniel Martin Buckley
Acked-by: Fan Zhang
Acked-by: Anoob Joseph
Acked-by: Konstantin Ananyev
---
doc/guides/rel_notes/deprecation.rst | 5 ++---
doc/guides/rel_notes/release_21_11.rst | 4
lib/security/rte_security.h| 7 +++
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index accb9c7d83..6517e7821f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -204,9 +204,8 @@ Deprecation Notices
pointer for the private data to the application which can be attached
to the packet while enqueuing.
-* security: The structure ``rte_security_ipsec_xform`` will be extended with
- multiple fields: source and destination port of UDP encapsulation,
- IPsec payload MSS (Maximum Segment Size).
+* security: The structure ``rte_security_ipsec_xform`` will be extended with:
+ new field: IPsec payload MSS (Maximum Segment Size).
* security: The IPsec SA config options ``struct
rte_security_ipsec_sa_options``
will be updated with new fields to support new features like TSO in case of
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 544d44b1a8..1748c2db05 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -274,6 +274,10 @@ ABI Changes
application to start from an arbitrary ESN value for debug and SA lifetime
enforcement purposes.
+* security: A new structure ``udp`` was added in structure
+ ``rte_security_ipsec_xform`` to allow setting the source and destination
ports
+ for UDP encapsulated IPsec traffic.
+
* bbdev: Added capability related to more comprehensive CRC options,
shifting values of the ``enum rte_bbdev_op_ldpcdec_flag_bitmasks``.
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 764ce83bca..17d0e95412 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -128,6 +128,11 @@ struct rte_security_ipsec_tunnel_param {
};
};
+struct rte_security_ipsec_udp_param {
+ uint16_t sport;
+ uint16_t dport;
+};
+
/**
* IPsec Security Association option flags
*/
@@ -326,6 +331,8 @@ struct rte_security_ipsec_xform {
};
} esn;
/**< Extended Sequence Number */
+ struct rte_security_ipsec_udp_param udp;
+ /**< UDP parameters, ignored when udp_encap option not specified */
};
/**
--
2.25.1
[dpdk-dev] [PATCH v9 04/10] ipsec: add support for NAT-T
Add support for the IPsec NAT-Traversal use case for Tunnel mode
packets.
Signed-off-by: Declan Doherty
Signed-off-by: Radu Nicolau
Signed-off-by: Abhijit Sinha
Signed-off-by: Daniel Martin Buckley
Acked-by: Fan Zhang
---
doc/guides/prog_guide/ipsec_lib.rst| 2 ++
doc/guides/rel_notes/release_21_11.rst | 1 +
lib/ipsec/esp_outb.c | 9 ++
lib/ipsec/rte_ipsec_sa.h | 9 +-
lib/ipsec/sa.c | 39 ++
5 files changed, 54 insertions(+), 6 deletions(-)
diff --git a/doc/guides/prog_guide/ipsec_lib.rst
b/doc/guides/prog_guide/ipsec_lib.rst
index 93e213bf36..af51ff8131 100644
--- a/doc/guides/prog_guide/ipsec_lib.rst
+++ b/doc/guides/prog_guide/ipsec_lib.rst
@@ -313,6 +313,8 @@ Supported features
* ESN and replay window.
+* NAT-T / UDP encapsulated ESP.
+
* algorithms: 3DES-CBC, AES-CBC, AES-CTR, AES-GCM, AES_CCM, CHACHA20_POLY1305,
AES_GMAC, HMAC-SHA1, NULL.
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 1748c2db05..e9fb169d44 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -157,6 +157,7 @@ New Features
* **IPsec library new features.**
* Added support for AEAD algorithms AES_CCM, CHACHA20_POLY1305 and AES_GMAC.
+ * Added support for NAT-T / UDP encapsulated ESP
Removed Items
diff --git a/lib/ipsec/esp_outb.c b/lib/ipsec/esp_outb.c
index a3f77469c3..0e3314b358 100644
--- a/lib/ipsec/esp_outb.c
+++ b/lib/ipsec/esp_outb.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
@@ -185,6 +186,14 @@ outb_tun_pkt_prepare(struct rte_ipsec_sa *sa, rte_be64_t
sqc,
/* copy tunnel pkt header */
rte_memcpy(ph, sa->hdr, sa->hdr_len);
+ /* if UDP encap is enabled update the dgram_len */
+ if (sa->type & RTE_IPSEC_SATP_NATT_ENABLE) {
+ struct rte_udp_hdr *udph = (struct rte_udp_hdr *)
+ (ph - sizeof(struct rte_udp_hdr));
+ udph->dgram_len = rte_cpu_to_be_16(mb->pkt_len - sqh_len -
+ sa->hdr_l3_off - sa->hdr_len);
+ }
+
/* update original and new ip header fields */
update_tun_outb_l3hdr(sa, ph + sa->hdr_l3_off, ph + hlen,
mb->pkt_len - sqh_len, sa->hdr_l3_off, sqn_low16(sqc));
diff --git a/lib/ipsec/rte_ipsec_sa.h b/lib/ipsec/rte_ipsec_sa.h
index cf51ad8338..3a22705055 100644
--- a/lib/ipsec/rte_ipsec_sa.h
+++ b/lib/ipsec/rte_ipsec_sa.h
@@ -78,6 +78,7 @@ struct rte_ipsec_sa_prm {
* - for TUNNEL outer IP version (IPv4/IPv6)
* - are SA SQN operations 'atomic'
* - ESN enabled/disabled
+ * - NAT-T UDP encapsulated (TUNNEL mode only)
* ...
*/
@@ -89,7 +90,8 @@ enum {
RTE_SATP_LOG2_SQN = RTE_SATP_LOG2_MODE + 2,
RTE_SATP_LOG2_ESN,
RTE_SATP_LOG2_ECN,
- RTE_SATP_LOG2_DSCP
+ RTE_SATP_LOG2_DSCP,
+ RTE_SATP_LOG2_NATT
};
#define RTE_IPSEC_SATP_IPV_MASK(1ULL << RTE_SATP_LOG2_IPV)
@@ -125,6 +127,11 @@ enum {
#define RTE_IPSEC_SATP_DSCP_DISABLE(0ULL << RTE_SATP_LOG2_DSCP)
#define RTE_IPSEC_SATP_DSCP_ENABLE (1ULL << RTE_SATP_LOG2_DSCP)
+#define RTE_IPSEC_SATP_NATT_MASK (1ULL << RTE_SATP_LOG2_NATT)
+#define RTE_IPSEC_SATP_NATT_DISABLE(0ULL << RTE_SATP_LOG2_NATT)
+#define RTE_IPSEC_SATP_NATT_ENABLE (1ULL << RTE_SATP_LOG2_NATT)
+
+
/**
* get type of given SA
* @return
diff --git a/lib/ipsec/sa.c b/lib/ipsec/sa.c
index 720e0f365b..2830506385 100644
--- a/lib/ipsec/sa.c
+++ b/lib/ipsec/sa.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
@@ -217,6 +218,10 @@ fill_sa_type(const struct rte_ipsec_sa_prm *prm, uint64_t
*type)
} else
return -EINVAL;
+ /* check for UDP encapsulation flag */
+ if (prm->ipsec_xform.options.udp_encap == 1)
+ tp |= RTE_IPSEC_SATP_NATT_ENABLE;
+
/* check for ESN flag */
if (prm->ipsec_xform.options.esn == 0)
tp |= RTE_IPSEC_SATP_ESN_DISABLE;
@@ -348,20 +353,36 @@ esp_outb_init(struct rte_ipsec_sa *sa, uint32_t hlen)
/*
* Init ESP outbound tunnel specific things.
*/
-static void
+static int
esp_outb_tun_init(struct rte_ipsec_sa *sa, const struct rte_ipsec_sa_prm *prm)
{
sa->proto = prm->tun.next_proto;
sa->hdr_len = prm->tun.hdr_len;
sa->hdr_l3_off = prm->tun.hdr_l3_off;
+ if (prm->tun.hdr_len > IPSEC_MAX_HDR_SIZE)
+ return -EINVAL;
+ memcpy(sa->hdr, prm->tun.hdr, prm->tun.hdr_len);
+
+ /* insert UDP header if UDP encapsulation is inabled */
+ if (sa->type & RTE_IPSEC_SATP_NATT_ENABLE) {
+ struct rte_udp_hdr *udph = (struct rte_udp_hdr *)
+ &sa->hdr[prm->tun.hdr_len];
+ sa->hdr_len += sizeof(struct rte_udp_hdr);
+ if (sa->hdr_len > IPSEC_MAX_HDR_SI
[dpdk-dev] [PATCH v9 05/10] mbuf: add IPsec ESP tunnel type
Add ESP tunnel type to the tunnel types list that can be specified
for TSO or checksum on the inner part of tunnel packets.
Signed-off-by: Declan Doherty
Signed-off-by: Radu Nicolau
Signed-off-by: Abhijit Sinha
Signed-off-by: Daniel Martin Buckley
Acked-by: Fan Zhang
Acked-by: Akhil Goyal
Acked-by: Olivier Matz
---
lib/mbuf/rte_mbuf_core.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
index 9d8e3ddc86..4747c0c452 100644
--- a/lib/mbuf/rte_mbuf_core.h
+++ b/lib/mbuf/rte_mbuf_core.h
@@ -255,6 +255,7 @@ extern "C" {
#define PKT_TX_TUNNEL_MPLSINUDP (0x5ULL << 45)
#define PKT_TX_TUNNEL_VXLAN_GPE (0x6ULL << 45)
#define PKT_TX_TUNNEL_GTP (0x7ULL << 45)
+#define PKT_TX_TUNNEL_ESP (0x8ULL << 45)
/**
* Generic IP encapsulated tunnel type, used for TSO and checksum offload.
* It can be used for tunnels which are not standards or listed above.
--
2.25.1
[dpdk-dev] [PATCH v9 06/10] ipsec: add transmit segmentation offload support
Add support for transmit segmentation offload to inline crypto processing
mode. This offload is not supported by other offload modes, as at a
minimum it requires inline crypto for IPsec to be supported on the
network interface.
Signed-off-by: Declan Doherty
Signed-off-by: Radu Nicolau
Signed-off-by: Abhijit Sinha
Signed-off-by: Daniel Martin Buckley
Acked-by: Fan Zhang
---
doc/guides/prog_guide/ipsec_lib.rst| 2 +
doc/guides/rel_notes/release_21_11.rst | 1 +
lib/ipsec/esp_outb.c | 120 +++--
3 files changed, 97 insertions(+), 26 deletions(-)
diff --git a/doc/guides/prog_guide/ipsec_lib.rst
b/doc/guides/prog_guide/ipsec_lib.rst
index af51ff8131..fc0af5eadb 100644
--- a/doc/guides/prog_guide/ipsec_lib.rst
+++ b/doc/guides/prog_guide/ipsec_lib.rst
@@ -315,6 +315,8 @@ Supported features
* NAT-T / UDP encapsulated ESP.
+* TSO support (only for inline crypto mode)
+
* algorithms: 3DES-CBC, AES-CBC, AES-CTR, AES-GCM, AES_CCM, CHACHA20_POLY1305,
AES_GMAC, HMAC-SHA1, NULL.
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index e9fb169d44..0a9c71d92e 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -158,6 +158,7 @@ New Features
* Added support for AEAD algorithms AES_CCM, CHACHA20_POLY1305 and AES_GMAC.
* Added support for NAT-T / UDP encapsulated ESP
+ * Added support TSO offload support; only supported for inline crypto mode.
Removed Items
diff --git a/lib/ipsec/esp_outb.c b/lib/ipsec/esp_outb.c
index 0e3314b358..d327c32a38 100644
--- a/lib/ipsec/esp_outb.c
+++ b/lib/ipsec/esp_outb.c
@@ -18,7 +18,7 @@
typedef int32_t (*esp_outb_prepare_t)(struct rte_ipsec_sa *sa, rte_be64_t sqc,
const uint64_t ivp[IPSEC_MAX_IV_QWORD], struct rte_mbuf *mb,
- union sym_op_data *icv, uint8_t sqh_len);
+ union sym_op_data *icv, uint8_t sqh_len, uint8_t tso);
/*
* helper function to fill crypto_sym op for cipher+auth algorithms.
@@ -139,7 +139,7 @@ outb_cop_prepare(struct rte_crypto_op *cop,
static inline int32_t
outb_tun_pkt_prepare(struct rte_ipsec_sa *sa, rte_be64_t sqc,
const uint64_t ivp[IPSEC_MAX_IV_QWORD], struct rte_mbuf *mb,
- union sym_op_data *icv, uint8_t sqh_len)
+ union sym_op_data *icv, uint8_t sqh_len, uint8_t tso)
{
uint32_t clen, hlen, l2len, pdlen, pdofs, plen, tlen;
struct rte_mbuf *ml;
@@ -157,11 +157,20 @@ outb_tun_pkt_prepare(struct rte_ipsec_sa *sa, rte_be64_t
sqc,
/* number of bytes to encrypt */
clen = plen + sizeof(*espt);
- clen = RTE_ALIGN_CEIL(clen, sa->pad_align);
+
+ /* We don't need to pad/align packet when using TSO offload */
+ if (!tso)
+ clen = RTE_ALIGN_CEIL(clen, sa->pad_align);
+
/* pad length + esp tail */
pdlen = clen - plen;
- tlen = pdlen + sa->icv_len + sqh_len;
+
+ /* We don't append ICV length when using TSO offload */
+ if (!tso)
+ tlen = pdlen + sa->icv_len + sqh_len;
+ else
+ tlen = pdlen + sqh_len;
/* do append and prepend */
ml = rte_pktmbuf_lastseg(mb);
@@ -309,7 +318,7 @@ esp_outb_tun_prepare(const struct rte_ipsec_session *ss,
struct rte_mbuf *mb[],
/* try to update the packet itself */
rc = outb_tun_pkt_prepare(sa, sqc, iv, mb[i], &icv,
- sa->sqh_len);
+ sa->sqh_len, 0);
/* success, setup crypto op */
if (rc >= 0) {
outb_pkt_xprepare(sa, sqc, &icv);
@@ -336,7 +345,7 @@ esp_outb_tun_prepare(const struct rte_ipsec_session *ss,
struct rte_mbuf *mb[],
static inline int32_t
outb_trs_pkt_prepare(struct rte_ipsec_sa *sa, rte_be64_t sqc,
const uint64_t ivp[IPSEC_MAX_IV_QWORD], struct rte_mbuf *mb,
- union sym_op_data *icv, uint8_t sqh_len)
+ union sym_op_data *icv, uint8_t sqh_len, uint8_t tso)
{
uint8_t np;
uint32_t clen, hlen, pdlen, pdofs, plen, tlen, uhlen;
@@ -358,11 +367,19 @@ outb_trs_pkt_prepare(struct rte_ipsec_sa *sa, rte_be64_t
sqc,
/* number of bytes to encrypt */
clen = plen + sizeof(*espt);
- clen = RTE_ALIGN_CEIL(clen, sa->pad_align);
+
+ /* We don't need to pad/align packet when using TSO offload */
+ if (!tso)
+ clen = RTE_ALIGN_CEIL(clen, sa->pad_align);
/* pad length + esp tail */
pdlen = clen - plen;
- tlen = pdlen + sa->icv_len + sqh_len;
+
+ /* We don't append ICV length when using TSO offload */
+ if (!tso)
+ tlen = pdlen + sa->icv_len + sqh_len;
+ else
+ tlen = pdlen + sqh_len;
/* do append and insert */
ml = rte_pktmbuf_lastseg(mb);
@@ -452,7 +469,7 @@ esp_outb_trs_prepare(const struct rte_ipsec_session *ss,
struct rte_mbuf *mb[],
[dpdk-dev] [PATCH v9 07/10] ipsec: add support for SA telemetry
Add telemetry support for ipsec SAs
Signed-off-by: Declan Doherty
Signed-off-by: Radu Nicolau
Signed-off-by: Abhijit Sinha
Signed-off-by: Daniel Martin Buckley
Acked-by: Fan Zhang
Acked-by: Konstantin Ananyev
---
doc/guides/prog_guide/ipsec_lib.rst| 7 +
doc/guides/rel_notes/release_21_11.rst | 1 +
lib/ipsec/esp_inb.c| 18 +-
lib/ipsec/esp_outb.c | 12 +-
lib/ipsec/ipsec_telemetry.c| 244 +
lib/ipsec/meson.build | 6 +-
lib/ipsec/rte_ipsec.h | 23 +++
lib/ipsec/sa.c | 10 +-
lib/ipsec/sa.h | 9 +
lib/ipsec/version.map | 9 +
10 files changed, 328 insertions(+), 11 deletions(-)
create mode 100644 lib/ipsec/ipsec_telemetry.c
diff --git a/doc/guides/prog_guide/ipsec_lib.rst
b/doc/guides/prog_guide/ipsec_lib.rst
index fc0af5eadb..2a262f8c51 100644
--- a/doc/guides/prog_guide/ipsec_lib.rst
+++ b/doc/guides/prog_guide/ipsec_lib.rst
@@ -321,6 +321,13 @@ Supported features
AES_GMAC, HMAC-SHA1, NULL.
+Telemetry support
+--
+Telemetry support implements SA details and IPsec packet add data counters
+statistics. Per SA telemetry statistics can be enabled using
+``rte_ipsec_telemetry_sa_add`` and disabled using
+``rte_ipsec_telemetry_sa_del``. Note that these calls are not thread safe.
+
Limitations
---
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 0a9c71d92e..70932fc8a9 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -159,6 +159,7 @@ New Features
* Added support for AEAD algorithms AES_CCM, CHACHA20_POLY1305 and AES_GMAC.
* Added support for NAT-T / UDP encapsulated ESP
* Added support TSO offload support; only supported for inline crypto mode.
+ * Added support for SA telemetry.
Removed Items
diff --git a/lib/ipsec/esp_inb.c b/lib/ipsec/esp_inb.c
index d66c88f05d..6fbe468a61 100644
--- a/lib/ipsec/esp_inb.c
+++ b/lib/ipsec/esp_inb.c
@@ -15,7 +15,7 @@
#include "misc.h"
#include "pad.h"
-typedef uint16_t (*esp_inb_process_t)(const struct rte_ipsec_sa *sa,
+typedef uint16_t (*esp_inb_process_t)(struct rte_ipsec_sa *sa,
struct rte_mbuf *mb[], uint32_t sqn[], uint32_t dr[], uint16_t num,
uint8_t sqh_len);
@@ -573,10 +573,10 @@ tun_process_step3(struct rte_mbuf *mb, uint64_t txof_msk,
uint64_t txof_val)
* *process* function for tunnel packets
*/
static inline uint16_t
-tun_process(const struct rte_ipsec_sa *sa, struct rte_mbuf *mb[],
+tun_process(struct rte_ipsec_sa *sa, struct rte_mbuf *mb[],
uint32_t sqn[], uint32_t dr[], uint16_t num, uint8_t sqh_len)
{
- uint32_t adj, i, k, tl;
+ uint32_t adj, i, k, tl, bytes;
uint32_t hl[num], to[num];
struct rte_esp_tail espt[num];
struct rte_mbuf *ml[num];
@@ -598,6 +598,7 @@ tun_process(const struct rte_ipsec_sa *sa, struct rte_mbuf
*mb[],
process_step1(mb[i], tlen, &ml[i], &espt[i], &hl[i], &to[i]);
k = 0;
+ bytes = 0;
for (i = 0; i != num; i++) {
adj = hl[i] + cofs;
@@ -621,10 +622,13 @@ tun_process(const struct rte_ipsec_sa *sa, struct
rte_mbuf *mb[],
tun_process_step3(mb[i], sa->tx_offload.msk,
sa->tx_offload.val);
k++;
+ bytes += mb[i]->pkt_len;
} else
dr[i - k] = i;
}
+ sa->statistics.count += k;
+ sa->statistics.bytes += bytes;
return k;
}
@@ -632,11 +636,11 @@ tun_process(const struct rte_ipsec_sa *sa, struct
rte_mbuf *mb[],
* *process* function for tunnel packets
*/
static inline uint16_t
-trs_process(const struct rte_ipsec_sa *sa, struct rte_mbuf *mb[],
+trs_process(struct rte_ipsec_sa *sa, struct rte_mbuf *mb[],
uint32_t sqn[], uint32_t dr[], uint16_t num, uint8_t sqh_len)
{
char *np;
- uint32_t i, k, l2, tl;
+ uint32_t i, k, l2, tl, bytes;
uint32_t hl[num], to[num];
struct rte_esp_tail espt[num];
struct rte_mbuf *ml[num];
@@ -656,6 +660,7 @@ trs_process(const struct rte_ipsec_sa *sa, struct rte_mbuf
*mb[],
process_step1(mb[i], tlen, &ml[i], &espt[i], &hl[i], &to[i]);
k = 0;
+ bytes = 0;
for (i = 0; i != num; i++) {
tl = tlen + espt[i].pad_len;
@@ -674,10 +679,13 @@ trs_process(const struct rte_ipsec_sa *sa, struct
rte_mbuf *mb[],
/* update mbuf's metadata */
trs_process_step3(mb[i]);
k++;
+ bytes += mb[i]->pkt_len;
} else
dr[i - k] = i;
}
+ sa->statistics.count += k;
+ sa->statistics.bytes += bytes;
return k;
}
diff --git a/lib/i
[dpdk-dev] [PATCH v9 08/10] ipsec: add support for initial SQN value
Update IPsec library to support initial SQN value.
Signed-off-by: Declan Doherty
Signed-off-by: Radu Nicolau
Signed-off-by: Abhijit Sinha
Signed-off-by: Daniel Martin Buckley
Acked-by: Fan Zhang
---
doc/guides/rel_notes/release_21_11.rst | 1 +
lib/ipsec/sa.c | 18 +++---
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 70932fc8a9..4ae9fe54d5 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -160,6 +160,7 @@ New Features
* Added support for NAT-T / UDP encapsulated ESP
* Added support TSO offload support; only supported for inline crypto mode.
* Added support for SA telemetry.
+ * Added support for setting a non default starting ESN value.
Removed Items
diff --git a/lib/ipsec/sa.c b/lib/ipsec/sa.c
index d767b2036a..d32f58dd1b 100644
--- a/lib/ipsec/sa.c
+++ b/lib/ipsec/sa.c
@@ -294,11 +294,11 @@ esp_inb_tun_init(struct rte_ipsec_sa *sa, const struct
rte_ipsec_sa_prm *prm)
* Init ESP outbound specific things.
*/
static void
-esp_outb_init(struct rte_ipsec_sa *sa, uint32_t hlen)
+esp_outb_init(struct rte_ipsec_sa *sa, uint32_t hlen, uint64_t sqn)
{
uint8_t algo_type;
- sa->sqn.outb = 1;
+ sa->sqn.outb = sqn > 1 ? sqn : 1;
algo_type = sa->algo_type;
@@ -380,7 +380,7 @@ esp_outb_tun_init(struct rte_ipsec_sa *sa, const struct
rte_ipsec_sa_prm *prm)
sa->tx_offload.val = rte_mbuf_tx_offload(sa->hdr_l3_off,
sa->hdr_len - sa->hdr_l3_off, 0, 0, 0, 0, 0);
- esp_outb_init(sa, sa->hdr_len);
+ esp_outb_init(sa, sa->hdr_len, prm->ipsec_xform.esn.value);
return 0;
}
@@ -509,7 +509,7 @@ esp_sa_init(struct rte_ipsec_sa *sa, const struct
rte_ipsec_sa_prm *prm,
case (RTE_IPSEC_SATP_DIR_OB | RTE_IPSEC_SATP_MODE_TRANS |
RTE_IPSEC_SATP_NATT_ENABLE):
case (RTE_IPSEC_SATP_DIR_OB | RTE_IPSEC_SATP_MODE_TRANS):
- esp_outb_init(sa, 0);
+ esp_outb_init(sa, 0, prm->ipsec_xform.esn.value);
break;
}
@@ -520,15 +520,19 @@ esp_sa_init(struct rte_ipsec_sa *sa, const struct
rte_ipsec_sa_prm *prm,
* helper function, init SA replay structure.
*/
static void
-fill_sa_replay(struct rte_ipsec_sa *sa, uint32_t wnd_sz, uint32_t nb_bucket)
+fill_sa_replay(struct rte_ipsec_sa *sa, uint32_t wnd_sz, uint32_t nb_bucket,
+ uint64_t sqn)
{
sa->replay.win_sz = wnd_sz;
sa->replay.nb_bucket = nb_bucket;
sa->replay.bucket_index_mask = nb_bucket - 1;
sa->sqn.inb.rsn[0] = (struct replay_sqn *)(sa + 1);
- if ((sa->type & RTE_IPSEC_SATP_SQN_MASK) == RTE_IPSEC_SATP_SQN_ATOM)
+ sa->sqn.inb.rsn[0]->sqn = sqn;
+ if ((sa->type & RTE_IPSEC_SATP_SQN_MASK) == RTE_IPSEC_SATP_SQN_ATOM) {
sa->sqn.inb.rsn[1] = (struct replay_sqn *)
((uintptr_t)sa->sqn.inb.rsn[0] + rsn_size(nb_bucket));
+ sa->sqn.inb.rsn[1]->sqn = sqn;
+ }
}
int
@@ -604,7 +608,7 @@ rte_ipsec_sa_init(struct rte_ipsec_sa *sa, const struct
rte_ipsec_sa_prm *prm,
/* fill replay window related fields */
if (nb != 0)
- fill_sa_replay(sa, wsz, nb);
+ fill_sa_replay(sa, wsz, nb, prm->ipsec_xform.esn.value);
return sz;
}
--
2.25.1
[dpdk-dev] [PATCH v9 09/10] doc: remove unneeded ipsec new field deprecation
The deprecation notice regarding extendig rte_ipsec_sa_prm with a new field hdr_l3_len is no longer applicable. Signed-off-by: Radu Nicolau --- doc/guides/rel_notes/deprecation.rst | 3 --- 1 file changed, 3 deletions(-) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 6517e7821f..d1bcd75327 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -211,9 +211,6 @@ Deprecation Notices will be updated with new fields to support new features like TSO in case of protocol offload. -* ipsec: The structure ``rte_ipsec_sa_prm`` will be extended with a new field - ``hdr_l3_len`` to configure tunnel L3 header length. - * eventdev: The file ``rte_eventdev_pmd.h`` will be renamed to ``eventdev_driver.h`` to make the driver interface as internal and the structures ``rte_eventdev_data``, ``rte_eventdev`` and ``rte_eventdevs`` will be moved to a new file named -- 2.25.1
[dpdk-dev] [PATCH v9 10/10] doc: remove unneeded security deprecation
The new fields regarding TSO support were not implemented following feedback, it was decided to implement TSO support by using existing mbuf fields. Signed-off-by: Radu Nicolau --- doc/guides/rel_notes/deprecation.rst | 7 --- 1 file changed, 7 deletions(-) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index d1bcd75327..53ce7466c0 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -204,13 +204,6 @@ Deprecation Notices pointer for the private data to the application which can be attached to the packet while enqueuing. -* security: The structure ``rte_security_ipsec_xform`` will be extended with: - new field: IPsec payload MSS (Maximum Segment Size). - -* security: The IPsec SA config options ``struct rte_security_ipsec_sa_options`` - will be updated with new fields to support new features like TSO in case of - protocol offload. - * eventdev: The file ``rte_eventdev_pmd.h`` will be renamed to ``eventdev_driver.h`` to make the driver interface as internal and the structures ``rte_eventdev_data``, ``rte_eventdev`` and ``rte_eventdevs`` will be moved to a new file named -- 2.25.1
[dpdk-dev] [PATCH v26 1/6] dmadev: introduce DMA device library
The 'dmadev' is a generic type of DMA device. This patch introduce the 'dmadev' device allocation functions. The infrastructure is prepared to welcome drivers in drivers/dma/ Signed-off-by: Chengwen Feng Acked-by: Bruce Richardson Acked-by: Morten Brørup Acked-by: Jerin Jacob Reviewed-by: Kevin Laatz Reviewed-by: Conor Walsh --- MAINTAINERS| 5 + doc/api/doxy-api-index.md | 1 + doc/api/doxy-api.conf.in | 1 + doc/guides/dmadevs/index.rst | 12 ++ doc/guides/index.rst | 1 + doc/guides/prog_guide/dmadev.rst | 58 + doc/guides/prog_guide/img/dmadev.svg | 283 + doc/guides/prog_guide/index.rst| 1 + doc/guides/rel_notes/release_21_11.rst | 5 + drivers/dma/meson.build| 4 + drivers/meson.build| 1 + lib/dmadev/meson.build | 6 + lib/dmadev/rte_dmadev.c| 246 + lib/dmadev/rte_dmadev.h| 133 lib/dmadev/rte_dmadev_pmd.h| 90 lib/dmadev/version.map | 20 ++ lib/meson.build| 1 + 17 files changed, 868 insertions(+) create mode 100644 doc/guides/dmadevs/index.rst create mode 100644 doc/guides/prog_guide/dmadev.rst create mode 100644 doc/guides/prog_guide/img/dmadev.svg create mode 100644 drivers/dma/meson.build create mode 100644 lib/dmadev/meson.build create mode 100644 lib/dmadev/rte_dmadev.c create mode 100644 lib/dmadev/rte_dmadev.h create mode 100644 lib/dmadev/rte_dmadev_pmd.h create mode 100644 lib/dmadev/version.map diff --git a/MAINTAINERS b/MAINTAINERS index 278e5b3226..119cfaa04e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -454,6 +454,11 @@ F: app/test-regex/ F: doc/guides/prog_guide/regexdev.rst F: doc/guides/regexdevs/features/default.ini +DMA device API - EXPERIMENTAL +M: Chengwen Feng +F: lib/dmadev/ +F: doc/guides/prog_guide/dmadev.rst + Eventdev API M: Jerin Jacob T: git://dpdk.org/next/dpdk-next-eventdev diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index 1992107a03..2939050431 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -21,6 +21,7 @@ The public API headers are grouped by topics: [compressdev](@ref rte_compressdev.h), [compress] (@ref rte_comp.h), [regexdev] (@ref rte_regexdev.h), + [dmadev] (@ref rte_dmadev.h), [eventdev] (@ref rte_eventdev.h), [event_eth_rx_adapter] (@ref rte_event_eth_rx_adapter.h), [event_eth_tx_adapter] (@ref rte_event_eth_tx_adapter.h), diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in index 325a0195c6..109ec1f682 100644 --- a/doc/api/doxy-api.conf.in +++ b/doc/api/doxy-api.conf.in @@ -35,6 +35,7 @@ INPUT = @TOPDIR@/doc/api/doxy-api-index.md \ @TOPDIR@/lib/compressdev \ @TOPDIR@/lib/cryptodev \ @TOPDIR@/lib/distributor \ + @TOPDIR@/lib/dmadev \ @TOPDIR@/lib/efd \ @TOPDIR@/lib/ethdev \ @TOPDIR@/lib/eventdev \ diff --git a/doc/guides/dmadevs/index.rst b/doc/guides/dmadevs/index.rst new file mode 100644 index 00..0bce29d766 --- /dev/null +++ b/doc/guides/dmadevs/index.rst @@ -0,0 +1,12 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright 2021 HiSilicon Limited + +DMA Device Drivers +== + +The following are a list of DMA device drivers, which can be used from +an application through DMA API. + +.. toctree:: + :maxdepth: 2 + :numbered: diff --git a/doc/guides/index.rst b/doc/guides/index.rst index 857f0363d3..919825992e 100644 --- a/doc/guides/index.rst +++ b/doc/guides/index.rst @@ -21,6 +21,7 @@ DPDK documentation compressdevs/index vdpadevs/index regexdevs/index + dmadevs/index eventdevs/index rawdevs/index mempool/index diff --git a/doc/guides/prog_guide/dmadev.rst b/doc/guides/prog_guide/dmadev.rst new file mode 100644 index 00..46b85ce217 --- /dev/null +++ b/doc/guides/prog_guide/dmadev.rst @@ -0,0 +1,58 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright 2021 HiSilicon Limited + +DMA Device Library +== + +The DMA library provides a DMA device framework for management and provisioning +of hardware and software DMA poll mode drivers, defining generic API which +support a number of different DMA operations. + + +Design Principles +- + +The DMA framework provides a generic DMA device framework which supports both +physical (hardware) and virtual (software) DMA devices, as well as a generic DMA +API which allows DMA devices to be managed and configured, and supports DMA +operations to be provisioned on DMA poll mode driver. + +.. _figure_dmadev: + +.. figure:: img/dmadev.* + +The
[dpdk-dev] [PATCH v26 2/6] dmadev: add control plane API support
This patch add control plane API for dmadev.
Signed-off-by: Chengwen Feng
Acked-by: Bruce Richardson
Acked-by: Morten Brørup
Reviewed-by: Kevin Laatz
Reviewed-by: Conor Walsh
---
doc/guides/prog_guide/dmadev.rst | 10 +
doc/guides/rel_notes/release_21_11.rst | 2 +
lib/dmadev/rte_dmadev.c| 361 +++
lib/dmadev/rte_dmadev.h| 465 +
lib/dmadev/rte_dmadev_pmd.h| 61
lib/dmadev/version.map | 9 +
6 files changed, 908 insertions(+)
diff --git a/doc/guides/prog_guide/dmadev.rst b/doc/guides/prog_guide/dmadev.rst
index 46b85ce217..b1b5bff639 100644
--- a/doc/guides/prog_guide/dmadev.rst
+++ b/doc/guides/prog_guide/dmadev.rst
@@ -56,3 +56,13 @@ identifiers:
- A device name used to designate the DMA device in console messages, for
administration or debugging purposes.
+
+
+Device Features and Capabilities
+
+
+DMA devices may support different feature sets. The ``rte_dma_info_get`` API
+can be used to get the device info and supported features.
+
+Silent mode is a special device capability which does not require the
+application to invoke dequeue APIs.
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 1c7c1d6eab..2953bc3e97 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -80,6 +80,8 @@ New Features
* Added a DMA device framework for management and provision of
hardware and software DMA devices.
+ * Added generic API which support a number of different DMA
+operations.
* **Updated af_packet ethdev driver.**
diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index 42a4693bd9..9223ae1c95 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -201,6 +201,9 @@ rte_dma_pmd_release(const char *name)
if (dev == NULL)
return -EINVAL;
+ if (dev->state == RTE_DMA_DEV_READY)
+ return rte_dma_close(dev->dev_id);
+
dma_release(dev);
return 0;
}
@@ -244,3 +247,361 @@ rte_dma_count_avail(void)
return count;
}
+
+int
+rte_dma_info_get(int16_t dev_id, struct rte_dma_info *dev_info)
+{
+ const struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+ int ret;
+
+ if (!rte_dma_is_valid(dev_id) || dev_info == NULL)
+ return -EINVAL;
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_info_get, -ENOTSUP);
+ memset(dev_info, 0, sizeof(struct rte_dma_info));
+ ret = (*dev->dev_ops->dev_info_get)(dev, dev_info,
+ sizeof(struct rte_dma_info));
+ if (ret != 0)
+ return ret;
+
+ dev_info->dev_name = dev->dev_name;
+ dev_info->numa_node = dev->device->numa_node;
+ dev_info->nb_vchans = dev->dev_conf.nb_vchans;
+
+ return 0;
+}
+
+int
+rte_dma_configure(int16_t dev_id, const struct rte_dma_conf *dev_conf)
+{
+ struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+ struct rte_dma_info dev_info;
+ int ret;
+
+ if (!rte_dma_is_valid(dev_id) || dev_conf == NULL)
+ return -EINVAL;
+
+ if (dev->dev_started != 0) {
+ RTE_DMA_LOG(ERR,
+ "Device %d must be stopped to allow configuration",
+ dev_id);
+ return -EBUSY;
+ }
+
+ ret = rte_dma_info_get(dev_id, &dev_info);
+ if (ret != 0) {
+ RTE_DMA_LOG(ERR, "Device %d get device info fail", dev_id);
+ return -EINVAL;
+ }
+ if (dev_conf->nb_vchans == 0) {
+ RTE_DMA_LOG(ERR,
+ "Device %d configure zero vchans", dev_id);
+ return -EINVAL;
+ }
+ if (dev_conf->nb_vchans > dev_info.max_vchans) {
+ RTE_DMA_LOG(ERR,
+ "Device %d configure too many vchans", dev_id);
+ return -EINVAL;
+ }
+ if (dev_conf->enable_silent &&
+ !(dev_info.dev_capa & RTE_DMA_CAPA_SILENT)) {
+ RTE_DMA_LOG(ERR, "Device %d don't support silent", dev_id);
+ return -EINVAL;
+ }
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -ENOTSUP);
+ ret = (*dev->dev_ops->dev_configure)(dev, dev_conf,
+sizeof(struct rte_dma_conf));
+ if (ret == 0)
+ memcpy(&dev->dev_conf, dev_conf, sizeof(struct rte_dma_conf));
+
+ return ret;
+}
+
+int
+rte_dma_start(int16_t dev_id)
+{
+ struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+ int ret;
+
+ if (!rte_dma_is_valid(dev_id))
+ return -EINVAL;
+
+ if (dev->dev_conf.nb_vchans == 0) {
+ RTE_DMA_LOG(ERR, "Device %d must be configured first", dev_id);
+ return -EINVAL;
+ }
+
+ if (dev->dev_started != 0) {
+
[dpdk-dev] [PATCH v26 4/6] dmadev: add multi-process support
This patch add multi-process support for dmadev.
Signed-off-by: Chengwen Feng
Acked-by: Bruce Richardson
Acked-by: Morten Brørup
Reviewed-by: Kevin Laatz
Reviewed-by: Conor Walsh
---
doc/guides/rel_notes/release_21_11.rst | 1 +
lib/dmadev/rte_dmadev.c| 183 -
lib/dmadev/rte_dmadev_core.h | 2 +-
lib/dmadev/rte_dmadev_pmd.h| 29 +++-
4 files changed, 169 insertions(+), 46 deletions(-)
diff --git a/doc/guides/rel_notes/release_21_11.rst
b/doc/guides/rel_notes/release_21_11.rst
index 2953bc3e97..888f123237 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -82,6 +82,7 @@ New Features
hardware and software DMA devices.
* Added generic API which support a number of different DMA
operations.
+ * Added multi-process support.
* **Updated af_packet ethdev driver.**
diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index 54e15817fa..7099bbb28d 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -19,6 +19,13 @@ static int16_t dma_devices_max;
struct rte_dma_fp_object *rte_dma_fp_objs;
struct rte_dma_dev *rte_dma_devices;
+static struct {
+ /* Hold the dev_max information of the primary process. This field is
+* set by the primary process and is read by the secondary process.
+*/
+ int16_t dev_max;
+ struct rte_dma_dev_data data[0];
+} *dma_devices_shared_data;
RTE_LOG_REGISTER_DEFAULT(rte_dma_logtype, INFO);
#define RTE_DMA_LOG(level, ...) \
@@ -70,11 +77,11 @@ dma_find_free_id(void)
{
int16_t i;
- if (rte_dma_devices == NULL)
+ if (rte_dma_devices == NULL || dma_devices_shared_data == NULL)
return -1;
for (i = 0; i < dma_devices_max; i++) {
- if (rte_dma_devices[i].state == RTE_DMA_DEV_UNUSED)
+ if (dma_devices_shared_data->data[i].dev_name[0] == '\0')
return i;
}
@@ -91,7 +98,7 @@ dma_find_by_name(const char *name)
for (i = 0; i < dma_devices_max; i++) {
if ((rte_dma_devices[i].state != RTE_DMA_DEV_UNUSED) &&
- (!strcmp(name, rte_dma_devices[i].dev_name)))
+ (!strcmp(name, rte_dma_devices[i].data->dev_name)))
return &rte_dma_devices[i];
}
@@ -147,23 +154,71 @@ dma_dev_data_prepare(void)
return 0;
}
+static int
+dma_shared_data_prepare(void)
+{
+ const char *mz_name = "rte_dma_dev_data";
+ const struct rte_memzone *mz;
+ size_t size;
+
+ if (dma_devices_shared_data != NULL)
+ return 0;
+
+ size = sizeof(*dma_devices_shared_data) +
+ sizeof(struct rte_dma_dev_data) * dma_devices_max;
+
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ mz = rte_memzone_reserve(mz_name, size, rte_socket_id(), 0);
+ else
+ mz = rte_memzone_lookup(mz_name);
+ if (mz == NULL)
+ return -ENOMEM;
+
+ dma_devices_shared_data = mz->addr;
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+ memset(dma_devices_shared_data, 0, size);
+ dma_devices_shared_data->dev_max = dma_devices_max;
+ } else {
+ dma_devices_max = dma_devices_shared_data->dev_max;
+ }
+
+ return 0;
+}
+
static int
dma_data_prepare(void)
{
int ret;
- if (dma_devices_max == 0)
- dma_devices_max = RTE_DMADEV_DEFAULT_MAX;
-
- ret = dma_fp_data_prepare();
- if (ret)
- return ret;
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+ if (dma_devices_max == 0)
+ dma_devices_max = RTE_DMADEV_DEFAULT_MAX;
+ ret = dma_fp_data_prepare();
+ if (ret)
+ return ret;
+ ret = dma_dev_data_prepare();
+ if (ret)
+ return ret;
+ ret = dma_shared_data_prepare();
+ if (ret)
+ return ret;
+ } else {
+ ret = dma_shared_data_prepare();
+ if (ret)
+ return ret;
+ ret = dma_fp_data_prepare();
+ if (ret)
+ return ret;
+ ret = dma_dev_data_prepare();
+ if (ret)
+ return ret;
+ }
- return dma_dev_data_prepare();
+ return 0;
}
static struct rte_dma_dev *
-dma_allocate(const char *name, int numa_node, size_t private_data_size)
+dma_allocate_primary(const char *name, int numa_node, size_t private_data_size)
{
struct rte_dma_dev *dev;
void *dev_private;
@@ -197,12 +252,59 @@ dma_allocate(const char *name, int numa_node, size_t
private_data_size)
}
dev = &rte_dma_devices[dev_id];
- rte_strscpy(dev->dev_name, name, sizeof(dev->dev_
