Re: [dpdk-dev] [PATCH v9 0/4] eal/windows: do not expose POSIX symbols
Hi Ranjit, 2021-04-12 21:46 (UTC-0700), Ranjit Menon: [...] > The change to remove the networking shim breaks l2fwd compilation on > Windows, since l2fwd/main.c includes netinet/in.h explicitly. > > How do you propose we fix this, only for Windows? This include is redundant for this file on all platforms, it can be removed. Since -Dexamples=all doesn't work on Windows because of missing dependencies, I wonder which of them need fixing.
Re: [dpdk-dev] [PATCH v5 1/4] vhost: abstract and reorganize async split ring code
Hi Cheng,
On 4/12/21 1:34 PM, Cheng Jiang wrote:
> In order to improve code efficiency and readability when async packed
> ring support is enabled. This patch abstract some functions like
> shadow_ring_store and write_back_completed_descs_split. And improve
> the efficiency of some pointer offset calculation.
>
> Signed-off-by: Cheng Jiang
> ---
> lib/librte_vhost/virtio_net.c | 146 +++---
> 1 file changed, 84 insertions(+), 62 deletions(-)
>
> diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
> index ff3987860..c43ab0093 100644
> --- a/lib/librte_vhost/virtio_net.c
> +++ b/lib/librte_vhost/virtio_net.c
> @@ -1458,6 +1458,29 @@ virtio_dev_rx_async_get_info_idx(uint16_t pkts_idx,
> (vq_size - n_inflight + pkts_idx) & (vq_size - 1);
> }
>
> +static __rte_always_inline void
> +shadow_ring_store(struct vhost_virtqueue *vq, void *shadow_ring, void
> *d_ring,
> + uint16_t s_idx, uint16_t d_idx,
> + uint16_t count, uint16_t elem_size)
> +{
> + if (d_idx + count <= vq->size) {
> + rte_memcpy((void *)((uintptr_t)d_ring + d_idx * elem_size),
> + (void *)((uintptr_t)shadow_ring + s_idx * elem_size),
> + count * elem_size);
> + } else {
> + uint16_t size = vq->size - d_idx;
> +
> + rte_memcpy((void *)((uintptr_t)d_ring + d_idx * elem_size),
> + (void *)((uintptr_t)shadow_ring + s_idx * elem_size),
> + size * elem_size);
> +
> + rte_memcpy((void *)((uintptr_t)d_ring),
> + (void *)((uintptr_t)shadow_ring +
> + (s_idx + size) * elem_size),
> + (count - size) * elem_size);
> + }
> +}
> +
> static __rte_noinline uint32_t
> virtio_dev_rx_async_submit_split(struct virtio_net *dev,
> struct vhost_virtqueue *vq, uint16_t queue_id,
> @@ -1478,6 +1501,7 @@ virtio_dev_rx_async_submit_split(struct virtio_net *dev,
> struct rte_vhost_iov_iter *dst_it = it_pool + 1;
> uint16_t slot_idx = 0;
> uint16_t segs_await = 0;
> + uint16_t iovec_idx = 0, it_idx = 0;
> struct async_inflight_info *pkts_info = vq->async_pkts_info;
> uint32_t n_pkts = 0, pkt_err = 0;
> uint32_t num_async_pkts = 0, num_done_pkts = 0;
> @@ -1513,27 +1537,32 @@ virtio_dev_rx_async_submit_split(struct virtio_net
> *dev,
>
> if (async_mbuf_to_desc(dev, vq, pkts[pkt_idx],
> buf_vec, nr_vec, num_buffers,
> - src_iovec, dst_iovec, src_it, dst_it) < 0) {
> + &src_iovec[iovec_idx],
> + &dst_iovec[iovec_idx],
> + &src_it[it_idx],
> + &dst_it[it_idx]) < 0) {
> vq->shadow_used_idx -= num_buffers;
> break;
> }
>
> slot_idx = (vq->async_pkts_idx + num_async_pkts) &
> (vq->size - 1);
> - if (src_it->count) {
> + if (src_it[it_idx].count) {
> uint16_t from, to;
>
> - async_fill_desc(&tdes[pkt_burst_idx++], src_it, dst_it);
> + async_fill_desc(&tdes[pkt_burst_idx++],
> + &src_it[it_idx],
> + &dst_it[it_idx]);
> pkts_info[slot_idx].descs = num_buffers;
> pkts_info[slot_idx].mbuf = pkts[pkt_idx];
> async_pkts_log[num_async_pkts].pkt_idx = pkt_idx;
> async_pkts_log[num_async_pkts++].last_avail_idx =
> vq->last_avail_idx;
> - src_iovec += src_it->nr_segs;
> - dst_iovec += dst_it->nr_segs;
> - src_it += 2;
> - dst_it += 2;
> - segs_await += src_it->nr_segs;
> +
> + iovec_idx += src_it[it_idx].nr_segs;
> + it_idx += 2;
> +
> + segs_await += src_it[it_idx].nr_segs;
>
> /**
>* recover shadow used ring and keep DMA-occupied
> @@ -1541,23 +1570,12 @@ virtio_dev_rx_async_submit_split(struct virtio_net
> *dev,
>*/
> from = vq->shadow_used_idx - num_buffers;
> to = vq->async_desc_idx & (vq->size - 1);
> - if (num_buffers + to <= vq->size) {
> - rte_memcpy(&vq->async_descs_split[to],
> - &vq->shadow_used_split[from],
> - num_buffers *
> - sizeof(struct vring_used_elem));
> - } else {
> - int size = vq->size - to;
Re: [dpdk-dev] [PATCH v2 1/2] ethdev: add packet integrity checks
Hi Ferruh, > -Original Message- > From: Ferruh Yigit > Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks > > On 4/12/2021 8:26 PM, Ori Kam wrote: > > Hi Ferruh, > > > >> -Original Message- > >> From: Ferruh Yigit > >> Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks > >> > >> On 4/11/2021 6:34 PM, Gregory Etelson wrote: > >>> From: Ori Kam > >>> > >>> Currently, DPDK application can offload the checksum check, > >>> and report it in the mbuf. > >>> > >>> However, as more and more applications are offloading some or all > >>> logic and action to the HW, there is a need to check the packet > >>> integrity so the right decision can be taken. > >>> > >>> The application logic can be positive meaning if the packet is > >>> valid jump / do actions, or negative if packet is not valid > >>> jump to SW / do actions (like drop) a, and add default flow > >>> (match all in low priority) that will direct the miss packet > >>> to the miss path. > >>> > >>> Since currenlty rte_flow works in positive way the assumtion is > >>> that the postive way will be the common way in this case also. > >>> > >>> When thinking what is the best API to implement such feature, > >>> we need to considure the following (in no specific order): > >>> 1. API breakage. > >>> 2. Simplicity. > >>> 3. Performance. > >>> 4. HW capabilities. > >>> 5. rte_flow limitation. > >>> 6. Flexability. > >>> > >>> First option: Add integrity flags to each of the items. > >>> For example add checksum_ok to ipv4 item. > >>> > >>> Pros: > >>> 1. No new rte_flow item. > >>> 2. Simple in the way that on each item the app can see > >>> what checks are available. > >>> > >>> Cons: > >>> 1. API breakage. > >>> 2. increase number of flows, since app can't add global rule and > >>> must have dedicated flow for each of the flow combinations, for > example > >>> matching on icmp traffic or UDP/TCP traffic with IPv4 / IPv6 will > >>> result in 5 flows. > >>> > >>> Second option: dedicated item > >>> > >>> Pros: > >>> 1. No API breakage, and there will be no for some time due to having > >>> extra space. (by using bits) > >>> 2. Just one flow to support the icmp or UDP/TCP traffic with IPv4 / > >>> IPv6. > >>> 3. Simplicity application can just look at one place to see all possible > >>> checks. > >>> 4. Allow future support for more tests. > >>> > >>> Cons: > >>> 1. New item, that holds number of fields from different items. > >>> > >>> For starter the following bits are suggested: > >>> 1. packet_ok - means that all HW checks depending on packet layer have > >>> passed. This may mean that in some HW such flow should be splited to > >>> number of flows or fail. > >>> 2. l2_ok - all check flor layer 2 have passed. > >>> 3. l3_ok - all check flor layer 2 have passed. If packet doens't have > >>> l3 layer this check shoudl fail. > >>> 4. l4_ok - all check flor layer 2 have passed. If packet doesn't > >>> have l4 layer this check should fail. > >>> 5. l2_crc_ok - the layer 2 crc is O.K. it is possible that the crc will > >>> be O.K. but the l3_ok will be 0. it is not possible that l2_crc_ok > >>> will > >>> be 0 and the l3_ok will be 0. > >>> 6. ipv4_csum_ok - IPv4 checksum is O.K. > >>> 7. l4_csum_ok - layer 4 checksum is O.K. > >>> 8. l3_len_OK - check that the reported layer 3 len is smaller than the > >>> packet len. > >>> > >>> Example of usage: > >>> 1. check packets from all possible layers for integrity. > >>> flow create integrity spec packet_ok = 1 mask packet_ok = 1 . > >>> > >>> 2. Check only packet with layer 4 (UDP / TCP) > >>> flow create integrity spec l3_ok = 1, l4_ok = 1 mask l3_ok = 1 l4_ok > >>> = 1 > >>> > >> > >> Hi Ori, > >> > >> Is the intention of the API just filtering, like apply some action to the > >> packets based on their integration status. Like drop packets their l2_crc > >> checksum failed? Here configuration is done by existing offload APIs. > >> > >> Or is the intention to configure the integration check on NIC, like to say > >> enable layer 2 checks, and do the action based on integration check status. > >> > > If I understand your question the first case is the one that this patch is > targeting. > > meaning based on those bits route/apply actions to the packet while still in > the > > HW. > > > > This is not design to enable the queue status bits. > > In the use case suggestion by this patch, just like you said the app > > can decide to drop the packet before arriving to the queue, application may > also > > use the mark + queue action to mark to the SW what is the issue with this > packet. > > > > I'm not sure I understand your comment about "here configuration is done by > existing > > offload API" do you mean like the drop / jump to table / any other rte_flow > action? > > > > > > I am asking because difference between device configuration and packet > filtering > seems getting more blurred in the fl
Re: [dpdk-dev] [pull-request] dpdk-next-net-eventdev - 21.05 - PRE-RC1
On Tue, Apr 13, 2021 at 12:12 AM Thomas Monjalon wrote: > > 12/04/2021 15:20, Jerin Jacob Kollanukkaran: > > http://dpdk.org/git/next/dpdk-next-eventdev > > Pulled, thanks. > > Note few changes in titles like uppercases for acronyms, > or "add support" simplified as "support", > and release notes moved in the right place. The ABI check now reports an error on event/dlb. The reason is that the event/dlb driver has been removed, and so the check complains about a missing dump. This will have to be fixed quickly or reverted. This has been missed by multiple people, so trying to understand why. The ABI check should have caught this when run by maintainers (/me looks at Thomas and Jerin). The CI should have caught it too. But, v1 did not apply. For v2, I can see a doc generation issue reported by Intel CI that I can't reproduce, so it could be just noise. I can't find reports for Travis or GHA and I could not find in the robot logs why the series_15708 branch was not created. Looking at UNH reports: http://mails.dpdk.org/archives/test-report/2021-March/182956.html But looking at the log: [2713/2716] Compiling C object 'drivers/a715181@@rte_event_octeontx2@sta/meson-generated_.._rte_event_octeontx2.pmd.c.o'. [2714/2716] Linking static target drivers/librte_event_octeontx2.a. [2715/2716] Generating rte_event_octeontx2.sym_chk with a meson_exe.py custom command. [2716/2716] Linking target drivers/librte_event_octeontx2.so.21.1. Error: cannot find librte_event_dlb.dump in /home-local/jenkins-local/jenkins-agent/workspace/Ubuntu18.04-Compile-DPDK-ABI/dpdk/build-gcc-shared/install Is this something that has been fixed since then? I don't have the main branch/recent series status from UNH, but at least GHA and Travis are now complaining about ABI. -- David Marchand
Re: [dpdk-dev] [PATCH v2 4/5] net/mlx5: add mlx5 APIs for single flow dump feature
HI Slava,
Yes for "we define 36/72 bytes array?".
Correction for my last comment, not byte , and it is one "int" for
port_id , 8 "int" for flowptr.
Sorry for the possible confusion.
-Original Message-
From: Haifei Luo
Sent: Tuesday, April 13, 2021 9:29 AM
To: Slava Ovsiienko ; dev@dpdk.org
Cc: Ori Kam ; Raslan Darawsheh ;
Xueming(Steven) Li ; Matan Azrad ;
Shahaf Shuler
Subject: RE: [PATCH v2 4/5] net/mlx5: add mlx5 APIs for single flow dump feature
Hi Slava,
For #1, The steering tool send messages to DPDK to request dump.
Server/Client use data structure "struct msghdr"
to communicate. It has " msg_iov " ," msg_iovlen" and etc.
In the tool side, Msg_iov is constructed as 1 byte for port_id, 8 bytes
for flowptr. In DPDK, then we parse the message this way.
For #2, I will move them to the beginning.
-Original Message-
From: Slava Ovsiienko
Sent: Monday, April 12, 2021 3:38 PM
To: Haifei Luo ; dev@dpdk.org
Cc: Ori Kam ; Raslan Darawsheh ;
Xueming(Steven) Li ; Haifei Luo ;
Matan Azrad ; Shahaf Shuler
Subject: RE: [PATCH v2 4/5] net/mlx5: add mlx5 APIs for single flow dump feature
> -Original Message-
> From: Haifei Luo
> Sent: Wednesday, April 7, 2021 9:09
> To: dev@dpdk.org
> Cc: Ori Kam ; Slava Ovsiienko
> ; Raslan Darawsheh ;
> Xueming(Steven) Li ; Haifei Luo
> ; Matan Azrad ; Shahaf Shuler
>
> Subject: [PATCH v2 4/5] net/mlx5: add mlx5 APIs for single flow dump
> feature
>
> Modify API mlx5_flow_dev_dump to support the feature.
> Modify mlx5_socket since one extra arg flow_ptr is added.
>
> Signed-off-by: Haifei Luo
Sorry, this patch is errorneously acked instead of the
"common/mlx5: add mlx5 APIs for single flow dump feature"
I have comment for this one.
> +#ifndef _GNU_SOURCE
> +#define _GNU_SOURCE
> +#endif
> +
> #include
> #include
> #include
> @@ -29,11 +33,15 @@
> {
> int conn_sock;
> int ret;
> + int j;
> struct cmsghdr *cmsg = NULL;
> - int data;
> + #define LENGTH 9
> + /* The first byte for port_id and the rest for flowptr. */
> + int data[LENGTH];
So, we define 36/72 bytes array? And then use each int as byte to save flow_idx
value?
I suppose the correct way would be to define the structure of message in stead
of using ints array, something likle this:
struct mlx5_ipc_msg {
int status;
void* flow_idx;
}
> + /* The first byte in data for port_id and the following 8 for flowptr */
> + for (j = 1; j < LENGTH; j++)
> + flow_ptr = (flow_ptr << 8) + data[j];
If structure is define, there should be:
flow_ptr = msg->flow_idx
> + if (flow_ptr == 0)
> + ret = mlx5_flow_dev_dump(dev, NULL, file, NULL);
> + else
> + ret = mlx5_flow_dev_dump(dev,
> + (struct rte_flow *)((uintptr_t)flow_ptr), file, &err);
> +
> + /*dump one*/
> + uint32_t handle_idx;
> + int ret;
> + struct mlx5_flow_handle *dh;
> + struct rte_flow *flow = mlx5_ipool_get(priv->sh->ipool
> + [MLX5_IPOOL_RTE_FLOW], (uintptr_t)(void *)flow_idx);
> +
Please, move variable declarations to the routine beginning, to others
With best regards, Slava
Re: [dpdk-dev] [PATCH v2 0/4] Change shared action API to action handle API
13/04/2021 03:22, Bing Zhao: > From: Ferruh Yigit > > > Bing Zhao (4): > > >ethdev: introduce indirect action APIs > > >app/test-pmd: change to indirect action command > > >doc: update user guide for indirect action > > >net/mlx5: adaption to indirect action API > > > > > > > Hi Bing, > > > > How the patchset constructed will cause build error in patch by > > patch build, since first patch removes some struct/functions that > > are in use. > > > > One way to handle this is: > > - first add new function/structs > > - switch app & pmd to new function/structs > > - remove old function/structs > > Sure, I will reorganize the patch set in this way. Thanks for this. This is a drop-in replacement, it should be done in one patch only.
Re: [dpdk-dev] [PATCH v1] net/ice: update QinQ switch filter handling
> -Original Message- > From: Wang, Haiyue > Sent: Tuesday, April 13, 2021 1:15 PM > To: dev@dpdk.org > Cc: Zhang, Qi Z ; Zhang, Yuying > ; Wang, Haiyue ; Yang, > Qiming > Subject: [PATCH v1] net/ice: update QinQ switch filter handling > > The hardware oueter/inner VLAN protocol types are now updated to map to > new interface VLAN protocol types, so update the application to use new VLAN > protocol types when the rte_flow is QinQ filter type. > > Signed-off-by: Haiyue Wang Acked-by: Qi Zhang Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [PATCH v2 0/4] Change shared action API to action handle API
Thanks, I will squash the commits. > -Original Message- > From: Thomas Monjalon > Sent: Tuesday, April 13, 2021 3:24 PM > To: Ferruh Yigit ; Bing Zhao > > Cc: Ori Kam ; andrew.rybche...@oktetlabs.ru; Matan > Azrad ; Slava Ovsiienko ; > dev@dpdk.org; ajit.khapa...@broadcom.com; Gregory Etelson > ; Andrey Vesnovaty > Subject: Re: [dpdk-dev] [PATCH v2 0/4] Change shared action API to > action handle API > > External email: Use caution opening links or attachments > > > 13/04/2021 03:22, Bing Zhao: > > From: Ferruh Yigit > > > > Bing Zhao (4): > > > >ethdev: introduce indirect action APIs > > > >app/test-pmd: change to indirect action command > > > >doc: update user guide for indirect action > > > >net/mlx5: adaption to indirect action API > > > > > > > > > > Hi Bing, > > > > > > How the patchset constructed will cause build error in patch by > > > patch build, since first patch removes some struct/functions > that > > > are in use. > > > > > > One way to handle this is: > > > - first add new function/structs > > > - switch app & pmd to new function/structs > > > - remove old function/structs > > > > Sure, I will reorganize the patch set in this way. Thanks for this. > > This is a drop-in replacement, it should be done in one patch only. > >
Re: [dpdk-dev] [pull-request] dpdk-next-net-eventdev - 21.05 - PRE-RC1
13/04/2021 09:15, David Marchand: > On Tue, Apr 13, 2021 at 12:12 AM Thomas Monjalon wrote: > > > > 12/04/2021 15:20, Jerin Jacob Kollanukkaran: > > > http://dpdk.org/git/next/dpdk-next-eventdev > > > > Pulled, thanks. > > > > Note few changes in titles like uppercases for acronyms, > > or "add support" simplified as "support", > > and release notes moved in the right place. > > The ABI check now reports an error on event/dlb. > The reason is that the event/dlb driver has been removed, and so the > check complains about a missing dump. > This will have to be fixed quickly or reverted. > > > This has been missed by multiple people, so trying to understand why. > > The ABI check should have caught this when run by maintainers (/me > looks at Thomas and Jerin). > > The CI should have caught it too. > But, v1 did not apply. > For v2, I can see a doc generation issue reported by Intel CI that I > can't reproduce, so it could be just noise. > I can't find reports for Travis or GHA and I could not find in the > robot logs why the series_15708 branch was not created. > > Looking at UNH reports: > http://mails.dpdk.org/archives/test-report/2021-March/182956.html > But looking at the log: > [2713/2716] Compiling C object > 'drivers/a715181@@rte_event_octeontx2@sta/meson-generated_.._rte_event_octeontx2.pmd.c.o'. > [2714/2716] Linking static target drivers/librte_event_octeontx2.a. > [2715/2716] Generating rte_event_octeontx2.sym_chk with a meson_exe.py > custom command. > [2716/2716] Linking target drivers/librte_event_octeontx2.so.21.1. > Error: cannot find librte_event_dlb.dump in > /home-local/jenkins-local/jenkins-agent/workspace/Ubuntu18.04-Compile-DPDK-ABI/dpdk/build-gcc-shared/install > > Is this something that has been fixed since then? > > I don't have the main branch/recent series status from UNH, but at > least GHA and Travis are now complaining about ABI. Sorry about that, this is because I stupidly thought I could fix it locally without thinking about the CI. I am going to send a patch for devtools/libabigail.abignore.
Re: [dpdk-dev] [PATCH v2 4/5] net/mlx5: add mlx5 APIs for single flow dump feature
> -Original Message-
> From: Haifei Luo
> Sent: Tuesday, April 13, 2021 9:29 AM
> To: Slava Ovsiienko ; dev@dpdk.org
> Cc: Ori Kam ; Raslan Darawsheh ;
> Xueming(Steven) Li ; Matan Azrad
> ; Shahaf Shuler
> Subject: RE: [PATCH v2 4/5] net/mlx5: add mlx5 APIs for single flow dump
> feature
>
> Hi Slava,
> For #1, The steering tool send messages to DPDK to request dump.
> Server/Client use data structure "struct msghdr"
> to communicate. It has " msg_iov " ," msg_iovlen" and etc.
> In the tool side, Msg_iov is constructed as 1 byte for port_id, 8
> bytes for
> flowptr. In DPDK, then we parse the message this way.
Yes, it is clear. In my opinion we should not use byte array and parse
we should present the some structure instead:
struct mlx5_flow_dump_req {
uint8_t port_id;
void *flow_id;
} __rte_packed;
BTW, why port_id is 1 byte? port_id in DPDK is 16-bit value.
If the request dump tool uses somr structure - it should be defined in some
common file. IMO, it is not a good practice to rely on raw byte array layout.
With best regards, Slava
> For #2, I will move them to the beginning.
>
> -Original Message-
> From: Slava Ovsiienko
> Sent: Monday, April 12, 2021 3:38 PM
> To: Haifei Luo ; dev@dpdk.org
> Cc: Ori Kam ; Raslan Darawsheh ;
> Xueming(Steven) Li ; Haifei Luo
> ; Matan Azrad ; Shahaf Shuler
>
> Subject: RE: [PATCH v2 4/5] net/mlx5: add mlx5 APIs for single flow dump
> feature
>
> > -Original Message-
> > From: Haifei Luo
> > Sent: Wednesday, April 7, 2021 9:09
> > To: dev@dpdk.org
> > Cc: Ori Kam ; Slava Ovsiienko
> > ; Raslan Darawsheh ;
> > Xueming(Steven) Li ; Haifei Luo
> > ; Matan Azrad ; Shahaf Shuler
> >
> > Subject: [PATCH v2 4/5] net/mlx5: add mlx5 APIs for single flow dump
> > feature
> >
> > Modify API mlx5_flow_dev_dump to support the feature.
> > Modify mlx5_socket since one extra arg flow_ptr is added.
> >
> > Signed-off-by: Haifei Luo
>
> Sorry, this patch is errorneously acked instead of the
> "common/mlx5: add mlx5 APIs for single flow dump feature"
>
> I have comment for this one.
>
> > +#ifndef _GNU_SOURCE
> > +#define _GNU_SOURCE
> > +#endif
> > +
> > #include
> > #include
> > #include
> > @@ -29,11 +33,15 @@
> > {
> > int conn_sock;
> > int ret;
> > + int j;
> > struct cmsghdr *cmsg = NULL;
> > - int data;
> > + #define LENGTH 9
> > + /* The first byte for port_id and the rest for flowptr. */
> > + int data[LENGTH];
>
> So, we define 36/72 bytes array? And then use each int as byte to save
> flow_idx value?
> I suppose the correct way would be to define the structure of message in
> stead of using ints array, something likle this:
>
> struct mlx5_ipc_msg {
> int status;
> void* flow_idx;
> }
>
> > + /* The first byte in data for port_id and the following 8 for flowptr */
> > + for (j = 1; j < LENGTH; j++)
> > + flow_ptr = (flow_ptr << 8) + data[j];
> If structure is define, there should be:
> flow_ptr = msg->flow_idx
>
> > + if (flow_ptr == 0)
> > + ret = mlx5_flow_dev_dump(dev, NULL, file, NULL);
> > + else
> > + ret = mlx5_flow_dev_dump(dev,
> > + (struct rte_flow *)((uintptr_t)flow_ptr), file, &err);
> > +
>
> > + /*dump one*/
> > + uint32_t handle_idx;
> > + int ret;
> > + struct mlx5_flow_handle *dh;
> > + struct rte_flow *flow = mlx5_ipool_get(priv->sh->ipool
> > + [MLX5_IPOOL_RTE_FLOW], (uintptr_t)(void *)flow_idx);
> > +
> Please, move variable declarations to the routine beginning, to others
>
> With best regards, Slava
Re: [dpdk-dev] [PATCH v4 1/2] ethdev: add new ext hdr for gtp psc
Hi and sorry for late response,
> -Original Message-
> From: Olivier Matz
> Sent: Thursday, April 8, 2021 5:11 PM
> To: Raslan Darawsheh
> Cc: dev@dpdk.org; ferruh.yi...@intel.com; Ori Kam ;
> andrew.rybche...@oktetlabs.ru; ivan.ma...@oktetlabs.ru;
> ying.a.w...@intel.com; Slava Ovsiienko ; Shiri
> Kuzin
> Subject: Re: [PATCH v4 1/2] ethdev: add new ext hdr for gtp psc
>
> On Thu, Apr 08, 2021 at 12:37:27PM +, Raslan Darawsheh wrote:
> > Hi Olivier,
> >
> > > -Original Message-
> > > From: Olivier Matz
> > > Sent: Thursday, April 8, 2021 3:30 PM
> > > To: Raslan Darawsheh
> > > Cc: dev@dpdk.org; ferruh.yi...@intel.com; Ori Kam ;
> > > andrew.rybche...@oktetlabs.ru; ivan.ma...@oktetlabs.ru;
> > > ying.a.w...@intel.com; Slava Ovsiienko ; Shiri
> > > Kuzin
> > > Subject: Re: [PATCH v4 1/2] ethdev: add new ext hdr for gtp psc
> > >
> > > Hi Raslan,
> > >
> > > On Sun, Apr 04, 2021 at 10:45:51AM +0300, Raslan Darawsheh wrote:
> > > > Define new rte header for gtp PDU session container
> > > > based on RFC 38415-g30
> > >
> > > Do you have a link to this RFC?
> > Yes sure,
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.3gpp.org%2Fftp%2FSpecs%2Farchive%2F38_series%2F38.415%2F38415-
> g30.zip&data=04%7C01%7Crasland%40nvidia.com%7C5279dde172024bc
> d1f6b08d8fa981668%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C6
> 37534878435191995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
> LuD7%2FvJgqJbZ78ncaM7UrpiLNPUt7zbPPfSMemyb2Y8%3D&reserved
> =0
> >
> > >
> > > > Signed-off-by: Raslan Darawsheh
> > > > ---
> > > > lib/librte_net/rte_gtp.h | 34
> ++
> > > > 1 file changed, 34 insertions(+)
> > > >
> > > > diff --git a/lib/librte_net/rte_gtp.h b/lib/librte_net/rte_gtp.h
> > > > index 6a6f9b238d..088b0b5a53 100644
> > > > --- a/lib/librte_net/rte_gtp.h
> > > > +++ b/lib/librte_net/rte_gtp.h
> > > > @@ -61,6 +61,40 @@ struct rte_gtp_hdr_ext_word {
> > > > uint8_t next_ext; /**< Next Extension Header Type. */
> > > > } __rte_packed;
> > > >
> > > > +/**
> > > > + * Optional extension for GTP with next_ext set to 0x85
> > > > + * defined based on RFC 38415-g30.
> > > > + */
> > > > +__extension__
> > > > +struct rte_gtp_psc_hdr {
> > > > + uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4
> > > > bytes */
> > > > + uint8_t type:4; /**< PDU type */
> > > > + uint8_t qmp:1; /**< Qos Monitoring Packet */
> > > > + union {
> > > > + struct {
> > > > + uint8_t snp:1; /**< Sequence number presence */
> > > > + uint8_t spare_dl1:2; /**< spare down link bits
> > > > */
> > > > + };
> > > > + struct {
> > > > + uint8_t dl_delay_ind:1; /**< dl delay result
> > > > presence
> > > */
> > > > + uint8_t ul_delay_ind:1; /**< ul delay result
> > > > presence
> > > */
> > > > + uint8_t snp_ul1:1; /**< Sequence number presence
> > > ul */
> > > > + };
> > > > + };
> > > > + union {
> > > > + struct {
> > > > + uint8_t ppp:1; /**< Paging policy presence */
> > > > + uint8_t rqi:1; /**< Reflective Qos Indicator */
> > > > + };
> > > > + struct {
> > > > + uint8_t n_delay_ind:1; /**< N3/N9 delay result
> > > presence */
> > > > + uint8_t spare_ul2:1; /**< spare up link bits */
> > > > + };
> > > > + };
> > > > + uint8_t qfi:6; /**< Qos Flow Identifier */
> > > > + uint8_t data[0]; /**< data feilds */
> > > > +} __rte_packed;
> > >
> > > With this header, sizeof(rte_gtp_psc_hdr) = 5, is it really expected?
> > The data[0] is variable length data, I guess I should send another version
> > to
> mention that in the comment maybe.
> > The header size according to the spec should be 4 octets aligned in general.
>
> What I wanted to highlight is that using union of structs containing
> bitfields does not work as you expect: each union is at least 1 byte.
> This results in a structure that does not match the expected header.
I see thanks for explaining.
>
> > >
> > > It would help to see the specification to have a better idea of how to
> > Sure, I've just posted the link above, please let me know of any suggestion
> that you have, and I'll be glad to do accordingly.
> >
> > > split, but a possible solution is to do something like this:
> > >
> > > struct rte_gtp_psc_generic_hdr {
> > > uint8_t ext_hdr_len;
> > > uint8_t type:4
> > > uint8_t qmp:1;
> > > uint8_t pad:3;
> > > };
> > >
> > > struct rte_gtp_psc__hdr {
> > > uint8_t ext_hdr_len;
> > > uint8_t type:4
> > > uint8_t qmp:1;
> > > uint8_t uint8_t snp:1;
> > > uint8_t spare_dl1:2;
> > > ...
> > > };
> > >
> > > ...
> > >
> > > struct
Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add packet mode in meter profile structure
On Mon, Apr 12, 2021 at 12:29 PM Jerin Jacob wrote: > > On Tue, Apr 13, 2021 at 12:54 AM Dumitrescu, Cristian > wrote: > > > > > > > > > -Original Message- > > > From: Li Zhang > > > Sent: Saturday, April 10, 2021 8:25 AM > > > To: dek...@nvidia.com; or...@nvidia.com; viachesl...@nvidia.com; > > > ma...@nvidia.com; shah...@nvidia.com; Dumitrescu, Cristian > > > ; lir...@marvell.com; Thomas Monjalon > > > ; Yigit, Ferruh ; Andrew > > > Rybchenko > > > Cc: dev@dpdk.org; rasl...@nvidia.com; ron...@nvidia.com > > > Subject: [PATCH v3 1/4] ethdev: add packet mode in meter profile structure > > > > > > Currently meter algorithms only supports rate is bytes per second(BPS). > > > Add packet_mode flag in meter profile parameters data structure. > > > So that it can meter traffic by packet per second. > > > > > > When packet_mode is 0, the profile rates and bucket sizes are > > > specified in bytes per second and bytes > > > when packet_mode is not 0, the profile rates and bucket sizes are > > > specified in packets and packets per second. > > > > > > The below structure will be extended: > > > rte_mtr_meter_profile > > > rte_mtr_capabilities > > > > > > Signed-off-by: Li Zhang > > > Acked-by: Matan Azrad > > > Acked-by: Jerin Jacob Acked-by: Ajit Khaparde
Re: [dpdk-dev] [PATCH v2] eventdev: fix case to initiate crypto adapter service
On Tue, Apr 13, 2021 at 04:08:40AM +, Gujjar, Abhinandan S wrote:
>
>
> > -Original Message-
> > From: Shijith Thotton
> > Sent: Monday, April 12, 2021 2:24 PM
> > To: dev@dpdk.org
> > Cc: Shijith Thotton ; Gujjar, Abhinandan S
> > ; Jerin Jacob ; Akhil
> > Goyal ; Anoob Joseph
> > Subject: [PATCH v2] eventdev: fix case to initiate crypto adapter service
> >
> > Initiate software crypto adapter service, only if hardware capabilities are
> > not
> > reported. In OP_FORWARD mode, software service is not required to
> > enqueue events if OP_FORWARD capability is supported by the PMD.
> >
> > Fixes: 7901eac3409a ("eventdev: add crypto adapter implementation")
> >
> > Signed-off-by: Shijith Thotton
> > ---
> > v2:
> > - Reworded commit message.
> >
> > lib/librte_eventdev/rte_event_crypto_adapter.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.c
> > b/lib/librte_eventdev/rte_event_crypto_adapter.c
> > index d903cdd48..e1d38d383 100644
> > --- a/lib/librte_eventdev/rte_event_crypto_adapter.c
> > +++ b/lib/librte_eventdev/rte_event_crypto_adapter.c
> > @@ -861,6 +861,7 @@ rte_event_crypto_adapter_queue_pair_add(uint8_t
> > id,
> > * b. OP_NEW mode -> SW Dequeue
> > */
> > if ((cap &
> > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW &&
> > +!(cap &
> > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD) &&
> The same check is below ORed with above condition.
> This is confusing. Could you recheck & do the necessary changes?
>
As per comments above, below checks are used to initiate SW service if:
1. PMDs supports OP_NEW, but not OP_FWD, in FWD mode.
2. Does not support OP_NEW and OP_FWD.
I have fixed the first point where only support for OP_NEW is checked in forward
mode, by adding a check for no OP_FWD capability.
> > adapter->mode ==
> > RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD) ||
> > (!(cap &
> > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW) &&
> > !(cap &
> > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD) &&
> > --
> > 2.25.1
>
Re: [dpdk-dev] [PATCH v2 2/2] app/testpmd: add support for integrity item
Hi Ferruh,
> -Original Message-
> From: Ferruh Yigit
>
> On 4/11/2021 6:34 PM, Gregory Etelson wrote:
> > From: Ori Kam
> >
> > The integrity item allows the application to match
> > on the integrity of a packet.
> >
> > use example:
> > match that packet integrity checks are ok. The checks depend on
> > packet layers. For example ICMP packet will not check L4 level.
> > flow create 0 ingress pattern integrity value mask 0x01 value spec 0x01
> > match that L4 packet is ok - check L2 & L3 & L4 layers:
> > flow create 0 ingress pattern integrity value mask 0xfe value spec 0xfe
> >
> > Signed-off-by: Ori Kam
> > Signed-off-by: Gregory Etelson
> > ---
> > v2 add testpmd patch
> > ---
> > app/test-pmd/cmdline_flow.c | 39
> +
>
> Hi Gregory, Ori,
>
> Can you add some samples to "testpmd_funcs.rst#flow-rules-management"?
>
> I asked in some other thread but did not get any response, what do you think
> to
> make 'testpmd_funcs.rst' sample update mandatory when testpmd flow added?
>
I fully agree that each new function should be mandatory,
The question is do we want that each new item / action (they use existing
function)
I think it is a bit of overhead but I don't have strong opinion.
>
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> > index fb7a3a8bd3..b5dec34325 100644
> > --- a/app/test-pmd/cmdline_flow.c
> > +++ b/app/test-pmd/cmdline_flow.c
> > @@ -289,6 +289,9 @@ enum index {
> > ITEM_GENEVE_OPT_TYPE,
> > ITEM_GENEVE_OPT_LENGTH,
> > ITEM_GENEVE_OPT_DATA,
> > + ITEM_INTEGRITY,
> > + ITEM_INTEGRITY_LEVEL,
> > + ITEM_INTEGRITY_VALUE,
> >
> > /* Validate/create actions. */
> > ACTIONS,
> > @@ -956,6 +959,7 @@ static const enum index next_item[] = {
> > ITEM_PFCP,
> > ITEM_ECPRI,
> > ITEM_GENEVE_OPT,
> > + ITEM_INTEGRITY,
> > END_SET,
> > ZERO,
> > };
> > @@ -1307,6 +1311,19 @@ static const enum index item_geneve_opt[] = {
> > ZERO,
> > };
> >
> > +static const enum index item_integrity[] = {
> > + ITEM_INTEGRITY_LEVEL,
> > + ITEM_INTEGRITY_VALUE,
> > + ZERO,
> > +};
> > +
> > +static const enum index item_integrity_lv[] = {
> > + ITEM_INTEGRITY_LEVEL,
> > + ITEM_INTEGRITY_VALUE,
> > + ITEM_NEXT,
> > + ZERO,
> > +};
> > +
> > static const enum index next_action[] = {
> > ACTION_END,
> > ACTION_VOID,
> > @@ -3373,6 +3390,28 @@ static const struct token token_list[] = {
> > (sizeof(struct rte_flow_item_geneve_opt),
> > ITEM_GENEVE_OPT_DATA_SIZE)),
> > },
> > + [ITEM_INTEGRITY] = {
> > + .name = "integrity",
> > + .help = "match packet integrity",
> > + .priv = PRIV_ITEM(INTEGRITY,
> > + sizeof(struct rte_flow_item_integrity)),
> > + .next = NEXT(item_integrity),
> > + .call = parse_vc,
> > + },
> > + [ITEM_INTEGRITY_LEVEL] = {
> > + .name = "level",
> > + .help = "integrity level",
> > + .next = NEXT(item_integrity_lv, NEXT_ENTRY(UNSIGNED),
> > +item_param),
> > + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_integrity,
> level)),
> > + },
> > + [ITEM_INTEGRITY_VALUE] = {
> > + .name = "value",
> > + .help = "integrity value",
> > + .next = NEXT(item_integrity_lv, NEXT_ENTRY(UNSIGNED),
> > +item_param),
> > + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_integrity,
> value)),
> > + },
> > /* Validate/create actions. */
> > [ACTIONS] = {
> > .name = "actions",
> >
Re: [dpdk-dev] [PATCH v2 1/2] ethdev: add packet integrity checks
On 4/13/2021 8:12 AM, Ori Kam wrote: Hi Ferruh, -Original Message- From: Ferruh Yigit Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks On 4/12/2021 8:26 PM, Ori Kam wrote: Hi Ferruh, -Original Message- From: Ferruh Yigit Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks On 4/11/2021 6:34 PM, Gregory Etelson wrote: From: Ori Kam Currently, DPDK application can offload the checksum check, and report it in the mbuf. However, as more and more applications are offloading some or all logic and action to the HW, there is a need to check the packet integrity so the right decision can be taken. The application logic can be positive meaning if the packet is valid jump / do actions, or negative if packet is not valid jump to SW / do actions (like drop) a, and add default flow (match all in low priority) that will direct the miss packet to the miss path. Since currenlty rte_flow works in positive way the assumtion is that the postive way will be the common way in this case also. When thinking what is the best API to implement such feature, we need to considure the following (in no specific order): 1. API breakage. 2. Simplicity. 3. Performance. 4. HW capabilities. 5. rte_flow limitation. 6. Flexability. First option: Add integrity flags to each of the items. For example add checksum_ok to ipv4 item. Pros: 1. No new rte_flow item. 2. Simple in the way that on each item the app can see what checks are available. Cons: 1. API breakage. 2. increase number of flows, since app can't add global rule and must have dedicated flow for each of the flow combinations, for example matching on icmp traffic or UDP/TCP traffic with IPv4 / IPv6 will result in 5 flows. Second option: dedicated item Pros: 1. No API breakage, and there will be no for some time due to having extra space. (by using bits) 2. Just one flow to support the icmp or UDP/TCP traffic with IPv4 / IPv6. 3. Simplicity application can just look at one place to see all possible checks. 4. Allow future support for more tests. Cons: 1. New item, that holds number of fields from different items. For starter the following bits are suggested: 1. packet_ok - means that all HW checks depending on packet layer have passed. This may mean that in some HW such flow should be splited to number of flows or fail. 2. l2_ok - all check flor layer 2 have passed. 3. l3_ok - all check flor layer 2 have passed. If packet doens't have l3 layer this check shoudl fail. 4. l4_ok - all check flor layer 2 have passed. If packet doesn't have l4 layer this check should fail. 5. l2_crc_ok - the layer 2 crc is O.K. it is possible that the crc will be O.K. but the l3_ok will be 0. it is not possible that l2_crc_ok will be 0 and the l3_ok will be 0. 6. ipv4_csum_ok - IPv4 checksum is O.K. 7. l4_csum_ok - layer 4 checksum is O.K. 8. l3_len_OK - check that the reported layer 3 len is smaller than the packet len. Example of usage: 1. check packets from all possible layers for integrity. flow create integrity spec packet_ok = 1 mask packet_ok = 1 . 2. Check only packet with layer 4 (UDP / TCP) flow create integrity spec l3_ok = 1, l4_ok = 1 mask l3_ok = 1 l4_ok = 1 Hi Ori, Is the intention of the API just filtering, like apply some action to the packets based on their integration status. Like drop packets their l2_crc checksum failed? Here configuration is done by existing offload APIs. Or is the intention to configure the integration check on NIC, like to say enable layer 2 checks, and do the action based on integration check status. If I understand your question the first case is the one that this patch is targeting. meaning based on those bits route/apply actions to the packet while still in the HW. This is not design to enable the queue status bits. In the use case suggestion by this patch, just like you said the app can decide to drop the packet before arriving to the queue, application may also use the mark + queue action to mark to the SW what is the issue with this packet. I'm not sure I understand your comment about "here configuration is done by existing offload API" do you mean like the drop / jump to table / any other rte_flow action? I am asking because difference between device configuration and packet filtering seems getting more blurred in the flow API. Currently L4 checksum offload is requested by application via setting 'DEV_RX_OFFLOAD_TCP_CKSUM' (UDP/SCTP/...) offload flags. This is the way to configure HW. Is the intention of this patch doing packet filtering after device configured with above offload API? Or is the intention HW to be configured via flow API, like if "l4_ok = 1" is set in the rule, will it enable L4 checks first and do the filtering later? If not what is the expected behavior when integration checks are not enabled when the rule is created? Let me try to explain it in
[dpdk-dev] [PATCH v4 0/3] support flow for IP fragment in ICE
Support RSS hash and FDIR for IP fragment packets in ICE PMD. v4: correct typo when define fragment v3: rebase code and fix some parsing issues. v2: add some input check Jeff Guo (3): net/ice/base: support IP fragment RSS and FDIR net/ice: support RSS hash for IP fragment net/ice: support FDIR for IP fragment packet drivers/net/ice/base/ice_fdir.c| 50 - drivers/net/ice/base/ice_fdir.h| 22 +- drivers/net/ice/base/ice_flow.c| 50 - drivers/net/ice/base/ice_flow.h| 5 +- drivers/net/ice/base/ice_type.h| 1 + drivers/net/ice/ice_fdir_filter.c | 116 ++--- drivers/net/ice/ice_generic_flow.c | 22 ++ drivers/net/ice/ice_generic_flow.h | 6 ++ drivers/net/ice/ice_hash.c | 48 ++-- 9 files changed, 293 insertions(+), 27 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH v4 1/3] net/ice/base: support IP fragment RSS and FDIR
Add support for IP fragment RSS hash and FDIR according to packet ID.
Separate IP fragment and IP other packet types.
Signed-off-by: Ting Xu
Signed-off-by: Jeff Guo
---
drivers/net/ice/base/ice_fdir.c | 50 +++--
drivers/net/ice/base/ice_fdir.h | 22 ---
drivers/net/ice/base/ice_flow.c | 50 -
drivers/net/ice/base/ice_flow.h | 5 +++-
drivers/net/ice/base/ice_type.h | 1 +
5 files changed, 120 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ice/base/ice_fdir.c b/drivers/net/ice/base/ice_fdir.c
index 2b39c13127..0eb7cdd729 100644
--- a/drivers/net/ice/base/ice_fdir.c
+++ b/drivers/net/ice/base/ice_fdir.c
@@ -518,6 +518,24 @@ static const u8 ice_fdir_ipv4_udp_ecpri_tp0_pkt[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};
+static const u8 ice_fdir_ipv6_frag_pkt[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x86, 0xDD, 0x60, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x2C, 0x40, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3B, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+};
+
+static const u8 ice_fdir_ipv4_frag_pkt[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x45, 0x00,
+ 0x00, 0x14, 0x00, 0x00, 0x20, 0x00, 0x40, 0x10,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00
+};
static const u8 ice_fdir_tcpv6_pkt[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x86, 0xDD, 0x60, 0x00,
@@ -716,6 +734,16 @@ static const struct ice_fdir_base_pkt ice_fdir_pkt[] = {
sizeof(ice_fdir_ipv4_pkt), ice_fdir_ipv4_pkt,
sizeof(ice_fdir_ip4_tun_pkt), ice_fdir_ip4_tun_pkt,
},
+ {
+ ICE_FLTR_PTYPE_FRAG_IPV4,
+ sizeof(ice_fdir_ipv4_pkt), ice_fdir_ipv4_frag_pkt,
+ sizeof(ice_fdir_ipv4_pkt), ice_fdir_ipv4_frag_pkt,
+ },
+ {
+ ICE_FLTR_PTYPE_FRAG_IPV6,
+ sizeof(ice_fdir_ipv6_frag_pkt), ice_fdir_ipv6_frag_pkt,
+ sizeof(ice_fdir_ipv6_frag_pkt), ice_fdir_ipv6_frag_pkt,
+ },
{
ICE_FLTR_PTYPE_NONF_IPV4_GTPU,
sizeof(ice_fdir_ipv4_gtpu4_pkt),
@@ -1505,7 +1533,7 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct
ice_fdir_fltr *input,
ice_pkt_insert_u8(loc, ICE_IPV4_TTL_OFFSET, input->ip.v4.ttl);
ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
if (frag)
- loc[20] = ICE_FDIR_IPV4_PKT_FLAG_DF;
+ loc[20] = ICE_FDIR_IPV4_PKT_FLAG_MF;
break;
case ICE_FLTR_PTYPE_NONF_IPV4_UDP:
ice_pkt_insert_mac_addr(pkt, input->ext_data_outer.dst_mac);
@@ -1808,6 +1836,23 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct
ice_fdir_fltr *input,
input->ip.v6.proto);
ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
break;
+ case ICE_FLTR_PTYPE_FRAG_IPV4:
+ ice_pkt_insert_u32(loc, ICE_IPV4_DST_ADDR_OFFSET,
+ input->ip.v4.src_ip);
+ ice_pkt_insert_u32(loc, ICE_IPV4_SRC_ADDR_OFFSET,
+ input->ip.v4.dst_ip);
+ ice_pkt_insert_u8(loc, ICE_IPV4_TOS_OFFSET, input->ip.v4.tos);
+ ice_pkt_insert_u16(loc, ICE_IPV4_ID_OFFSET,
+ input->ip.v4.packet_id);
+ ice_pkt_insert_u8(loc, ICE_IPV4_TTL_OFFSET, input->ip.v4.ttl);
+ ice_pkt_insert_u8(loc, ICE_IPV4_PROTO_OFFSET,
+ input->ip.v4.proto);
+ ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
+ break;
+ case ICE_FLTR_PTYPE_FRAG_IPV6:
+ ice_pkt_insert_u32(loc, ICE_IPV6_ID_OFFSET,
+ input->ip.v6.packet_id);
+ break;
default:
return ICE_ERR_PARAM;
}
@@ -1838,7 +1883,8 @@ ice_fdir_get_prgm_pkt(struct ice_fdir_fltr *input, u8
*pkt, bool frag)
*/
bool ice_fdir_has_frag(enum ice_fltr_ptype flow)
{
- if (flow == ICE_FLTR_PTYPE_NONF_IPV4_OTHER)
+ if (flow == ICE_FLTR_PTYPE_FRAG_IPV4 ||
+ flow == ICE_FLTR_PTYPE_FRAG_IPV6)
return true;
else
return false;
diff --git a/drivers/net/ice/base/ice_fdir.h b/drivers/net/ice/base/ice_fdir.h
index 6573f96bc1..2acc1d6f1b 100644
--- a/drivers/net/ice/base/ice_fdir.h
+++ b/drivers/net/ice/base/ice_fdir.h
@@ -43,9 +43,11 @@
#define ICE_MAC_ETHTYPE_OFFSET 12
#define ICE_IPV4_TOS_OFFSET15
#define ICE_IPV4_TTL_OFFSET
[dpdk-dev] [PATCH v4 3/3] net/ice: support FDIR for IP fragment packet
New FDIR parsing are added to handle the fragmented IPv4/IPv6 packet.
Signed-off-by: Jeff Guo
Signed-off-by: Ting Xu
---
drivers/net/ice/base/ice_fdir.c| 4 +-
drivers/net/ice/ice_fdir_filter.c | 116 ++---
drivers/net/ice/ice_generic_flow.c | 1 +
3 files changed, 108 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ice/base/ice_fdir.c b/drivers/net/ice/base/ice_fdir.c
index 0eb7cdd729..a9a14b7445 100644
--- a/drivers/net/ice/base/ice_fdir.c
+++ b/drivers/net/ice/base/ice_fdir.c
@@ -736,8 +736,8 @@ static const struct ice_fdir_base_pkt ice_fdir_pkt[] = {
},
{
ICE_FLTR_PTYPE_FRAG_IPV4,
- sizeof(ice_fdir_ipv4_pkt), ice_fdir_ipv4_frag_pkt,
- sizeof(ice_fdir_ipv4_pkt), ice_fdir_ipv4_frag_pkt,
+ sizeof(ice_fdir_ipv4_frag_pkt), ice_fdir_ipv4_frag_pkt,
+ sizeof(ice_fdir_ipv4_frag_pkt), ice_fdir_ipv4_frag_pkt,
},
{
ICE_FLTR_PTYPE_FRAG_IPV6,
diff --git a/drivers/net/ice/ice_fdir_filter.c
b/drivers/net/ice/ice_fdir_filter.c
index 92e18d59cc..8158f75f05 100644
--- a/drivers/net/ice/ice_fdir_filter.c
+++ b/drivers/net/ice/ice_fdir_filter.c
@@ -24,7 +24,7 @@
#define ICE_FDIR_INSET_ETH_IPV4 (\
ICE_FDIR_INSET_ETH | \
ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | ICE_INSET_IPV4_TOS | \
- ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO)
+ ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO | ICE_INSET_IPV4_PKID)
#define ICE_FDIR_INSET_ETH_IPV4_UDP (\
ICE_FDIR_INSET_ETH_IPV4 | \
@@ -41,7 +41,8 @@
#define ICE_FDIR_INSET_ETH_IPV6 (\
ICE_INSET_DMAC | \
ICE_INSET_IPV6_SRC | ICE_INSET_IPV6_DST | ICE_INSET_IPV6_TC | \
- ICE_INSET_IPV6_HOP_LIMIT | ICE_INSET_IPV6_NEXT_HDR)
+ ICE_INSET_IPV6_HOP_LIMIT | ICE_INSET_IPV6_NEXT_HDR | \
+ ICE_INSET_IPV6_PKID)
#define ICE_FDIR_INSET_ETH_IPV6_UDP (\
ICE_FDIR_INSET_ETH_IPV6 | \
@@ -56,7 +57,8 @@
ICE_INSET_SCTP_SRC_PORT | ICE_INSET_SCTP_DST_PORT)
#define ICE_FDIR_INSET_IPV4 (\
- ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST)
+ ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | \
+ ICE_INSET_IPV4_PKID)
#define ICE_FDIR_INSET_IPV4_TCP (\
ICE_FDIR_INSET_IPV4 | \
@@ -95,6 +97,7 @@ static struct ice_pattern_match_item ice_fdir_pattern_list[]
= {
{pattern_eth_ipv4_tcp,
ICE_FDIR_INSET_ETH_IPV4_TCP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv4_sctp,
ICE_FDIR_INSET_ETH_IPV4_SCTP, ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6,
ICE_FDIR_INSET_ETH_IPV6,ICE_INSET_NONE, ICE_INSET_NONE},
+ {pattern_eth_ipv6_frag_ext,
ICE_FDIR_INSET_ETH_IPV6,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_udp,
ICE_FDIR_INSET_ETH_IPV6_UDP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_tcp,
ICE_FDIR_INSET_ETH_IPV6_TCP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_sctp,
ICE_FDIR_INSET_ETH_IPV6_SCTP, ICE_INSET_NONE, ICE_INSET_NONE},
@@ -882,11 +885,13 @@ ice_fdir_input_set_parse(uint64_t inset, enum
ice_flow_field *field)
{ICE_INSET_IPV4_TOS, ICE_FLOW_FIELD_IDX_IPV4_DSCP},
{ICE_INSET_IPV4_TTL, ICE_FLOW_FIELD_IDX_IPV4_TTL},
{ICE_INSET_IPV4_PROTO, ICE_FLOW_FIELD_IDX_IPV4_PROT},
+ {ICE_INSET_IPV4_PKID, ICE_FLOW_FIELD_IDX_IPV4_ID},
{ICE_INSET_IPV6_SRC, ICE_FLOW_FIELD_IDX_IPV6_SA},
{ICE_INSET_IPV6_DST, ICE_FLOW_FIELD_IDX_IPV6_DA},
{ICE_INSET_IPV6_TC, ICE_FLOW_FIELD_IDX_IPV6_DSCP},
{ICE_INSET_IPV6_NEXT_HDR, ICE_FLOW_FIELD_IDX_IPV6_PROT},
{ICE_INSET_IPV6_HOP_LIMIT, ICE_FLOW_FIELD_IDX_IPV6_TTL},
+ {ICE_INSET_IPV6_PKID, ICE_FLOW_FIELD_IDX_IPV6_ID},
{ICE_INSET_TCP_SRC_PORT, ICE_FLOW_FIELD_IDX_TCP_SRC_PORT},
{ICE_INSET_TCP_DST_PORT, ICE_FLOW_FIELD_IDX_TCP_DST_PORT},
{ICE_INSET_UDP_SRC_PORT, ICE_FLOW_FIELD_IDX_UDP_SRC_PORT},
@@ -936,6 +941,10 @@ ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow, struct
ice_flow_seg_info *seg)
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV4 |
ICE_FLOW_SEG_HDR_IPV_OTHER);
break;
+ case ICE_FLTR_PTYPE_FRAG_IPV4:
+ ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV4 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG);
+ break;
case ICE_FLTR_PTYPE_NONF_IPV6_UDP:
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_UDP |
ICE_FLOW_SEG_HDR_IPV6 |
@@ -955,6 +964,10 @@ ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow, struct
ic
[dpdk-dev] [PATCH v4 2/3] net/ice: support RSS hash for IP fragment
New pattern and RSS hash flow parsing are added to handle fragmented
IPv4/IPv6 packet.
Signed-off-by: Jeff Guo
---
drivers/net/ice/ice_generic_flow.c | 21 +
drivers/net/ice/ice_generic_flow.h | 6
drivers/net/ice/ice_hash.c | 48 +-
3 files changed, 67 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ice/ice_generic_flow.c
b/drivers/net/ice/ice_generic_flow.c
index 8704812622..2389bc6637 100644
--- a/drivers/net/ice/ice_generic_flow.c
+++ b/drivers/net/ice/ice_generic_flow.c
@@ -212,6 +212,27 @@ enum rte_flow_item_type pattern_eth_qinq_ipv6[] = {
RTE_FLOW_ITEM_TYPE_IPV6,
RTE_FLOW_ITEM_TYPE_END,
};
+enum rte_flow_item_type pattern_eth_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+enum rte_flow_item_type pattern_eth_vlan_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+enum rte_flow_item_type pattern_eth_qinq_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
enum rte_flow_item_type pattern_eth_ipv6_udp[] = {
RTE_FLOW_ITEM_TYPE_ETH,
RTE_FLOW_ITEM_TYPE_IPV6,
diff --git a/drivers/net/ice/ice_generic_flow.h
b/drivers/net/ice/ice_generic_flow.h
index 9f422e5925..2afe719264 100644
--- a/drivers/net/ice/ice_generic_flow.h
+++ b/drivers/net/ice/ice_generic_flow.h
@@ -52,6 +52,7 @@
#define ICE_L2TPV3OIP_SESSION_ID BIT_ULL(43)
#define ICE_PFCP_SEID BIT_ULL(42)
#define ICE_PFCP_S_FIELD BIT_ULL(41)
+#define ICE_IP_PK_ID BIT_ULL(40)
/* input set */
@@ -69,11 +70,13 @@
#define ICE_INSET_IPV4_TOS (ICE_PROT_IPV4 | ICE_IP_TOS)
#define ICE_INSET_IPV4_PROTO (ICE_PROT_IPV4 | ICE_IP_PROTO)
#define ICE_INSET_IPV4_TTL (ICE_PROT_IPV4 | ICE_IP_TTL)
+#define ICE_INSET_IPV4_PKID(ICE_PROT_IPV4 | ICE_IP_PK_ID)
#define ICE_INSET_IPV6_SRC (ICE_PROT_IPV6 | ICE_IP_SRC)
#define ICE_INSET_IPV6_DST (ICE_PROT_IPV6 | ICE_IP_DST)
#define ICE_INSET_IPV6_NEXT_HDR(ICE_PROT_IPV6 | ICE_IP_PROTO)
#define ICE_INSET_IPV6_HOP_LIMIT (ICE_PROT_IPV6 | ICE_IP_TTL)
#define ICE_INSET_IPV6_TC (ICE_PROT_IPV6 | ICE_IP_TOS)
+#define ICE_INSET_IPV6_PKID(ICE_PROT_IPV6 | ICE_IP_PK_ID)
#define ICE_INSET_TCP_SRC_PORT (ICE_PROT_TCP | ICE_SPORT)
#define ICE_INSET_TCP_DST_PORT (ICE_PROT_TCP | ICE_DPORT)
@@ -202,6 +205,9 @@ extern enum rte_flow_item_type pattern_eth_qinq_ipv4_icmp[];
extern enum rte_flow_item_type pattern_eth_ipv6[];
extern enum rte_flow_item_type pattern_eth_vlan_ipv6[];
extern enum rte_flow_item_type pattern_eth_qinq_ipv6[];
+extern enum rte_flow_item_type pattern_eth_ipv6_frag_ext[];
+extern enum rte_flow_item_type pattern_eth_vlan_ipv6_frag_ext[];
+extern enum rte_flow_item_type pattern_eth_qinq_ipv6_frag_ext[];
extern enum rte_flow_item_type pattern_eth_ipv6_udp[];
extern enum rte_flow_item_type pattern_eth_vlan_ipv6_udp[];
extern enum rte_flow_item_type pattern_eth_qinq_ipv6_udp[];
diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
index 7d7e7052da..9df20df550 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -47,8 +47,10 @@
ETH_RSS_NONFRAG_IPV6_TCP | \
ETH_RSS_NONFRAG_IPV6_SCTP)
-#define VALID_RSS_IPV4 (ETH_RSS_IPV4 | VALID_RSS_IPV4_L4)
-#define VALID_RSS_IPV6 (ETH_RSS_IPV6 | VALID_RSS_IPV6_L4)
+#define VALID_RSS_IPV4 (ETH_RSS_IPV4 | ETH_RSS_FRAG_IPV4 | \
+VALID_RSS_IPV4_L4)
+#define VALID_RSS_IPV6 (ETH_RSS_IPV6 | ETH_RSS_FRAG_IPV6 | \
+VALID_RSS_IPV6_L4)
#define VALID_RSS_L3 (VALID_RSS_IPV4 | VALID_RSS_IPV6)
#define VALID_RSS_L4 (VALID_RSS_IPV4_L4 | VALID_RSS_IPV6_L4)
@@ -108,6 +110,7 @@ ice_hash_parse_pattern_action(struct ice_adapter *ad,
/* Rss configuration template */
struct ice_rss_hash_cfg ipv4_tmplt = {
ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG |
ICE_FLOW_SEG_HDR_IPV_OTHER,
ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV4,
ICE_RSS_OUTER_HEADERS,
@@ -146,6 +149,15 @@ struct ice_rss_hash_cfg ipv6_tmplt = {
0
};
+struct ice_rss_hash_cfg ipv6_frag_tmplt = {
+ ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV6 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG |
+ ICE_FLOW_SEG_HDR_IPV_OTHER,
+ ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV6,
+ ICE_RSS_ANY_HEADERS,
+ 0
+};
+
struct ice_rss_hash_cfg
[dpdk-dev] [v2] test/mempool: fix heap buffer overflow
Amount of allocated memory was not enough for mempool
which cause buffer overflow when access fields of mempool
private structure in the rte_pktmbuf_priv_size function.
Fixes: 923ceaeac140 ("test/mempool: add unit test cases")
Cc: sta...@dpdk.org
Signed-off-by: Wenwu Ma
---
v2:
- refine commit log.
---
app/test/test_mempool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 084842fda..fc06a9c6f 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -543,7 +543,8 @@ test_mempool(void)
mp_stack_mempool_iter = rte_mempool_create("test_iter_obj",
MEMPOOL_SIZE,
MEMPOOL_ELT_SIZE,
- RTE_MEMPOOL_CACHE_MAX_SIZE, 0,
+ RTE_MEMPOOL_CACHE_MAX_SIZE,
+ sizeof(struct rte_pktmbuf_pool_private),
NULL, NULL,
my_obj_init, NULL,
SOCKET_ID_ANY, 0);
--
2.25.1
[dpdk-dev] [v2] test/mempool: fix heap buffer overflow
Amount of allocated memory was not enough for mempool
which cause buffer overflow when access fields of mempool
private structure in the rte_pktmbuf_priv_size function.
Fixes: 923ceaeac140 ("test/mempool: add unit test cases")
Cc: sta...@dpdk.org
Signed-off-by: Wenwu Ma
---
v2:
- refine commit log.
---
app/test/test_mempool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 084842fda..fc06a9c6f 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -543,7 +543,8 @@ test_mempool(void)
mp_stack_mempool_iter = rte_mempool_create("test_iter_obj",
MEMPOOL_SIZE,
MEMPOOL_ELT_SIZE,
- RTE_MEMPOOL_CACHE_MAX_SIZE, 0,
+ RTE_MEMPOOL_CACHE_MAX_SIZE,
+ sizeof(struct rte_pktmbuf_pool_private),
NULL, NULL,
my_obj_init, NULL,
SOCKET_ID_ANY, 0);
--
2.25.1
Re: [dpdk-dev] [PATCH v2 2/2] app/testpmd: add support for integrity item
On 4/13/2021 8:53 AM, Ori Kam wrote:
Hi Ferruh,
-Original Message-
From: Ferruh Yigit
On 4/11/2021 6:34 PM, Gregory Etelson wrote:
From: Ori Kam
The integrity item allows the application to match
on the integrity of a packet.
use example:
match that packet integrity checks are ok. The checks depend on
packet layers. For example ICMP packet will not check L4 level.
flow create 0 ingress pattern integrity value mask 0x01 value spec 0x01
match that L4 packet is ok - check L2 & L3 & L4 layers:
flow create 0 ingress pattern integrity value mask 0xfe value spec 0xfe
Signed-off-by: Ori Kam
Signed-off-by: Gregory Etelson
---
v2 add testpmd patch
---
app/test-pmd/cmdline_flow.c | 39
+
Hi Gregory, Ori,
Can you add some samples to "testpmd_funcs.rst#flow-rules-management"?
I asked in some other thread but did not get any response, what do you think to
make 'testpmd_funcs.rst' sample update mandatory when testpmd flow added?
I fully agree that each new function should be mandatory,
What is new function here, new flow API? That should go to flow API
documentation, 'rte_flow.rst'.
The question is do we want that each new item / action (they use existing
function)
I think it is a bit of overhead but I don't have strong opinion.
Since the documentation is for the testpmd usage sample, I was thinking to add
sample for each new item & action indeed.
Same of the flow rules not widely used, and it is not always clear how to use
them, that is why I believe documenting samples can help.
1 file changed, 39 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index fb7a3a8bd3..b5dec34325 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -289,6 +289,9 @@ enum index {
ITEM_GENEVE_OPT_TYPE,
ITEM_GENEVE_OPT_LENGTH,
ITEM_GENEVE_OPT_DATA,
+ ITEM_INTEGRITY,
+ ITEM_INTEGRITY_LEVEL,
+ ITEM_INTEGRITY_VALUE,
/* Validate/create actions. */
ACTIONS,
@@ -956,6 +959,7 @@ static const enum index next_item[] = {
ITEM_PFCP,
ITEM_ECPRI,
ITEM_GENEVE_OPT,
+ ITEM_INTEGRITY,
END_SET,
ZERO,
};
@@ -1307,6 +1311,19 @@ static const enum index item_geneve_opt[] = {
ZERO,
};
+static const enum index item_integrity[] = {
+ ITEM_INTEGRITY_LEVEL,
+ ITEM_INTEGRITY_VALUE,
+ ZERO,
+};
+
+static const enum index item_integrity_lv[] = {
+ ITEM_INTEGRITY_LEVEL,
+ ITEM_INTEGRITY_VALUE,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3373,6 +3390,28 @@ static const struct token token_list[] = {
(sizeof(struct rte_flow_item_geneve_opt),
ITEM_GENEVE_OPT_DATA_SIZE)),
},
+ [ITEM_INTEGRITY] = {
+ .name = "integrity",
+ .help = "match packet integrity",
+ .priv = PRIV_ITEM(INTEGRITY,
+ sizeof(struct rte_flow_item_integrity)),
+ .next = NEXT(item_integrity),
+ .call = parse_vc,
+ },
+ [ITEM_INTEGRITY_LEVEL] = {
+ .name = "level",
+ .help = "integrity level",
+ .next = NEXT(item_integrity_lv, NEXT_ENTRY(UNSIGNED),
+item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_integrity,
level)),
+ },
+ [ITEM_INTEGRITY_VALUE] = {
+ .name = "value",
+ .help = "integrity value",
+ .next = NEXT(item_integrity_lv, NEXT_ENTRY(UNSIGNED),
+item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_integrity,
value)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
Re: [dpdk-dev] [PATCH v4 2/2] ethdev: update qfi definition
Hi,
> -Original Message-
> From: Ferruh Yigit
> Sent: Tuesday, April 6, 2021 7:10 PM
> To: Raslan Darawsheh ; dev@dpdk.org; Ori Kam
> ; andrew.rybche...@oktetlabs.ru
> Cc: ivan.ma...@oktetlabs.ru; ying.a.w...@intel.com;
> olivier.m...@6wind.com; Slava Ovsiienko ; Shiri
> Kuzin ; sta...@dpdk.org; David Marchand
> ; NBU-Contact-Thomas Monjalon
>
> Subject: Re: [PATCH v4 2/2] ethdev: update qfi definition
>
> On 4/4/2021 8:45 AM, Raslan Darawsheh wrote:
> > qfi field is 8 bits which represent single bit for
> > PPP (paging Policy Presence) single bit for RQI
> > (Reflective QoS Indicator) and 6 bits for qfi
> > (QoS Flow Identifier) based on RFC 38415-g30
> >
> > This update the doxygen format and the mask for qfi
> > to properly identify the full 8 bits of the field.
> >
> > note: changing the default mask would cause different
> > patterns generated by testpmd.
> >
> > Fixes: 346553db5bd1 ("ethdev: add GTP extension header to flow API")
> > Cc: ying.a.w...@intel.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Raslan Darawsheh
> > ---
> > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 ++-
> > lib/librte_ethdev/rte_flow.h| 20 +---
> > 2 files changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > index f59eb8a27d..dd39c4c3c2 100644
> > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > @@ -3742,7 +3742,8 @@ This section lists supported pattern items and
> their attributes, if any.
> > - ``gtp_psc``: match GTP PDU extension header with type 0x85.
> >
> > - ``pdu_type {unsigned}``: PDU type.
> > - - ``qfi {unsigned}``: QoS flow identifier.
> > +
> > + - ``qfi {unsigned}``: PPP, RQI and QoS flow identifier.
> >
> > - ``pppoes``, ``pppoed``: match PPPoE header.
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > index 6cc57136ac..20b4389429 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1421,16 +1422,29 @@ static const struct rte_flow_item_meta
> rte_flow_item_meta_mask = {
> >*
> >* Matches a GTP PDU extension header with type 0x85.
> >*/
> > +RTE_STD_C11
> > struct rte_flow_item_gtp_psc {
> > - uint8_t pdu_type; /**< PDU type. */
> > - uint8_t qfi; /**< QoS flow identifier. */
> > + union {
> > + struct {
> > + /*
> > +* These fields are retained for compatibility.
> > +* Please switch to the new header field below.
> > +*/
> > + uint8_t pdu_type; /**< PDU type. */
> > + uint8_t qfi; /**< PPP, RQI, QoS flow identifier. */
> > +
> > + };
> > + struct rte_gtp_psc_hdr hdr;
> > + };
> > };
>
> This will change the struct size even with union, since old version is missing
> all fields from protocol header. Struct size will go from 2 --> 5 bytes [1].
>
> Since this is public struct, we can't change its size.
>
> @Ori, Andrew,
>
> Do you have a suggestion for next step?
>
> - We can still add the "struct rte_gtp_psc_hdr", and add a deprecation notice
> for "struct rte_flow_item_gtp_psc" to say it will use "struct
> rte_gtp_psc_hdr"
> on 21.11.
>
> - And for this release use the Raslan's first version:
>- uint8_t qfi; /**< QoS flow identifier. */
>+ uint8_t qfi; /**< PPP, RQI, QoS flow identifier. */
>
>
> Does it make sense? Any comments?
>
@Ori Kam, @andrew.rybche...@oktetlabs.ru,
This is a kind remainder of this patch,
>
>
> [1]
> struct rte_gtp_psc_hdr {
> uint8_text_hdr_len; /* 0 1 */
> uint8_ttype:4; /* 1: 0 1 */
> uint8_tqmp:1;/* 1: 4 1 */
>
> /* XXX 3 bits hole, try to pack */
>
> union {
> struct {
> uint8_tsnp:1;/* 2: 0 1 */
> uint8_tspare_dl1:2; /* 2: 1 1 */
> }; /* 2 1 */
> struct {
> uint8_tdl_delay_ind:1; /* 2: 0 1 */
> uint8_tul_delay_ind:1; /* 2: 1 1 */
> uint8_tsnp_ul1:1;/* 2: 2 1 */
> }; /* 2 1 */
> }; /* 2 1 */
> union {
> struct {
> uint8_tppp:1;/* 3: 0 1 */
> uint8_trqi:1;
[dpdk-dev] [PATCH v4 0/4] support flow for IP fragment in IAVF
support flow for IP fragment in IAVF v4: add some part which should not be deleted v3: rebase code and fix some parsing issues v2: refine some input check Jeff Guo (4): app/testpmd: add packet id for IP fragment common/iavf: add proto header for IP fragment net/iavf: support RSS hash for IP fragment net/iavf: support FDIR for IP fragment packet app/test-pmd/cmdline_flow.c | 21 +- drivers/common/iavf/virtchnl.h | 7 + drivers/net/iavf/iavf_fdir.c | 386 ++- drivers/net/iavf/iavf_generic_flow.c | 24 ++ drivers/net/iavf/iavf_generic_flow.h | 8 + drivers/net/iavf/iavf_hash.c | 83 +- 6 files changed, 394 insertions(+), 135 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH v4 2/4] common/iavf: add proto header for IP fragment
Add new virtchnl protocol header type and fields for IP fragment packets
to support RSS hash and FDIR.
Signed-off-by: Ting Xu
Signed-off-by: Jeff Guo
---
drivers/common/iavf/virtchnl.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/common/iavf/virtchnl.h b/drivers/common/iavf/virtchnl.h
index 6b99e170f0..e3eb767d66 100644
--- a/drivers/common/iavf/virtchnl.h
+++ b/drivers/common/iavf/virtchnl.h
@@ -1415,7 +1415,9 @@ enum virtchnl_proto_hdr_type {
VIRTCHNL_PROTO_HDR_S_VLAN,
VIRTCHNL_PROTO_HDR_C_VLAN,
VIRTCHNL_PROTO_HDR_IPV4,
+ VIRTCHNL_PROTO_HDR_IPV4_FRAG,
VIRTCHNL_PROTO_HDR_IPV6,
+ VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG,
VIRTCHNL_PROTO_HDR_TCP,
VIRTCHNL_PROTO_HDR_UDP,
VIRTCHNL_PROTO_HDR_SCTP,
@@ -1452,6 +1454,8 @@ enum virtchnl_proto_hdr_field {
VIRTCHNL_PROTO_HDR_IPV4_DSCP,
VIRTCHNL_PROTO_HDR_IPV4_TTL,
VIRTCHNL_PROTO_HDR_IPV4_PROT,
+ VIRTCHNL_PROTO_HDR_IPV4_FRAG_PKID =
+ PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_IPV4_FRAG),
/* IPV6 */
VIRTCHNL_PROTO_HDR_IPV6_SRC =
PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_IPV6),
@@ -1472,6 +1476,9 @@ enum virtchnl_proto_hdr_field {
VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_DST,
VIRTCHNL_PROTO_HDR_IPV6_PREFIX96_SRC,
VIRTCHNL_PROTO_HDR_IPV6_PREFIX96_DST,
+ /* IPv6 Extension Header Fragment */
+ VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG_PKID =
+ PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG),
/* TCP */
VIRTCHNL_PROTO_HDR_TCP_SRC_PORT =
PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_TCP),
--
2.20.1
[dpdk-dev] [PATCH v4 4/4] net/iavf: support FDIR for IP fragment packet
New FDIR parsing are added to handle the fragmented IPv4/IPv6 packet.
Signed-off-by: Ting Xu
Signed-off-by: Jeff Guo
---
drivers/net/iavf/iavf_fdir.c | 386 ++-
drivers/net/iavf/iavf_generic_flow.h | 5 +
2 files changed, 267 insertions(+), 124 deletions(-)
diff --git a/drivers/net/iavf/iavf_fdir.c b/drivers/net/iavf/iavf_fdir.c
index 62f032985a..f238a83c84 100644
--- a/drivers/net/iavf/iavf_fdir.c
+++ b/drivers/net/iavf/iavf_fdir.c
@@ -34,7 +34,7 @@
#define IAVF_FDIR_INSET_ETH_IPV4 (\
IAVF_INSET_IPV4_SRC | IAVF_INSET_IPV4_DST | \
IAVF_INSET_IPV4_PROTO | IAVF_INSET_IPV4_TOS | \
- IAVF_INSET_IPV4_TTL)
+ IAVF_INSET_IPV4_TTL | IAVF_INSET_IPV4_ID)
#define IAVF_FDIR_INSET_ETH_IPV4_UDP (\
IAVF_INSET_IPV4_SRC | IAVF_INSET_IPV4_DST | \
@@ -56,6 +56,9 @@
IAVF_INSET_IPV6_NEXT_HDR | IAVF_INSET_IPV6_TC | \
IAVF_INSET_IPV6_HOP_LIMIT)
+#define IAVF_FDIR_INSET_ETH_IPV6_FRAG_EXT (\
+ IAVF_INSET_IPV6_ID)
+
#define IAVF_FDIR_INSET_ETH_IPV6_UDP (\
IAVF_INSET_IPV6_SRC | IAVF_INSET_IPV6_DST | \
IAVF_INSET_IPV6_TC | IAVF_INSET_IPV6_HOP_LIMIT | \
@@ -143,6 +146,7 @@ static struct iavf_pattern_match_item iavf_fdir_pattern[] =
{
{iavf_pattern_eth_ipv4_tcp, IAVF_FDIR_INSET_ETH_IPV4_TCP,
IAVF_INSET_NONE},
{iavf_pattern_eth_ipv4_sctp, IAVF_FDIR_INSET_ETH_IPV4_SCTP,
IAVF_INSET_NONE},
{iavf_pattern_eth_ipv6, IAVF_FDIR_INSET_ETH_IPV6,
IAVF_INSET_NONE},
+ {iavf_pattern_eth_ipv6_frag_ext,
IAVF_FDIR_INSET_ETH_IPV6_FRAG_EXT, IAVF_INSET_NONE},
{iavf_pattern_eth_ipv6_udp, IAVF_FDIR_INSET_ETH_IPV6_UDP,
IAVF_INSET_NONE},
{iavf_pattern_eth_ipv6_tcp, IAVF_FDIR_INSET_ETH_IPV6_TCP,
IAVF_INSET_NONE},
{iavf_pattern_eth_ipv6_sctp, IAVF_FDIR_INSET_ETH_IPV6_SCTP,
IAVF_INSET_NONE},
@@ -543,6 +547,29 @@ iavf_fdir_refine_input_set(const uint64_t input_set,
}
}
+static void
+iavf_fdir_add_fragment_hdr(struct virtchnl_proto_hdrs *hdrs, int layer)
+{
+ struct virtchnl_proto_hdr *hdr1;
+ struct virtchnl_proto_hdr *hdr2;
+ int i;
+
+ if (layer < 0 || layer > hdrs->count)
+ return;
+
+ /* shift headers layer */
+ for (i = hdrs->count; i >= layer; i--) {
+ hdr1 = &hdrs->proto_hdr[i];
+ hdr2 = &hdrs->proto_hdr[i - 1];
+ *hdr1 = *hdr2;
+ }
+
+ /* adding dummy fragment header */
+ hdr1 = &hdrs->proto_hdr[layer];
+ VIRTCHNL_SET_PROTO_HDR_TYPE(hdr1, IPV4_FRAG);
+ hdrs->count = ++layer;
+}
+
static int
iavf_fdir_parse_pattern(__rte_unused struct iavf_adapter *ad,
const struct rte_flow_item pattern[],
@@ -550,12 +577,15 @@ iavf_fdir_parse_pattern(__rte_unused struct iavf_adapter
*ad,
struct rte_flow_error *error,
struct iavf_fdir_conf *filter)
{
- const struct rte_flow_item *item = pattern;
- enum rte_flow_item_type item_type;
+ struct virtchnl_proto_hdrs *hdrs =
+ &filter->add_fltr.rule_cfg.proto_hdrs;
enum rte_flow_item_type l3 = RTE_FLOW_ITEM_TYPE_END;
const struct rte_flow_item_eth *eth_spec, *eth_mask;
- const struct rte_flow_item_ipv4 *ipv4_spec, *ipv4_mask;
+ const struct rte_flow_item_ipv4 *ipv4_spec, *ipv4_last, *ipv4_mask;
const struct rte_flow_item_ipv6 *ipv6_spec, *ipv6_mask;
+ const struct rte_flow_item_ipv6_frag_ext *ipv6_frag_spec;
+ const struct rte_flow_item_ipv6_frag_ext *ipv6_frag_last;
+ const struct rte_flow_item_ipv6_frag_ext *ipv6_frag_mask;
const struct rte_flow_item_udp *udp_spec, *udp_mask;
const struct rte_flow_item_tcp *tcp_spec, *tcp_mask;
const struct rte_flow_item_sctp *sctp_spec, *sctp_mask;
@@ -566,15 +596,15 @@ iavf_fdir_parse_pattern(__rte_unused struct iavf_adapter
*ad,
const struct rte_flow_item_ah *ah_spec, *ah_mask;
const struct rte_flow_item_pfcp *pfcp_spec, *pfcp_mask;
const struct rte_flow_item_ecpri *ecpri_spec, *ecpri_mask;
+ const struct rte_flow_item *item = pattern;
+ struct virtchnl_proto_hdr *hdr, *hdr1 = NULL;
struct rte_ecpri_common_hdr ecpri_common;
uint64_t input_set = IAVF_INSET_NONE;
-
+ enum rte_flow_item_type item_type;
enum rte_flow_item_type next_type;
+ uint8_t tun_inner = 0;
uint16_t ether_type;
-
- u8 tun_inner = 0;
int layer = 0;
- struct virtchnl_proto_hdr *hdr;
uint8_t ipv6_addr_mask[16] = {
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
@@ -582,26 +612,28 @@ iavf_fdir_parse_pattern(__rte_unused struct iavf_adapter
*ad,
};
for (item = pattern; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
- if (item->last) {
+ item_type = item->type;
[dpdk-dev] [PATCH v4 1/4] app/testpmd: add packet id for IP fragment
Add the new items to support the flow configuration for IP fragment
packets.
Signed-off-by: Ting Xu
Signed-off-by: Jeff Guo
---
app/test-pmd/cmdline_flow.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index fb7a3a8bd3..46ae342b85 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -166,6 +166,7 @@ enum index {
ITEM_VLAN_HAS_MORE_VLAN,
ITEM_IPV4,
ITEM_IPV4_TOS,
+ ITEM_IPV4_ID,
ITEM_IPV4_FRAGMENT_OFFSET,
ITEM_IPV4_TTL,
ITEM_IPV4_PROTO,
@@ -236,6 +237,7 @@ enum index {
ITEM_IPV6_FRAG_EXT,
ITEM_IPV6_FRAG_EXT_NEXT_HDR,
ITEM_IPV6_FRAG_EXT_FRAG_DATA,
+ ITEM_IPV6_FRAG_EXT_ID,
ITEM_ICMP6,
ITEM_ICMP6_TYPE,
ITEM_ICMP6_CODE,
@@ -1028,6 +1030,7 @@ static const enum index item_vlan[] = {
static const enum index item_ipv4[] = {
ITEM_IPV4_TOS,
+ ITEM_IPV4_ID,
ITEM_IPV4_FRAGMENT_OFFSET,
ITEM_IPV4_TTL,
ITEM_IPV4_PROTO,
@@ -1164,6 +1167,7 @@ static const enum index item_ipv6_ext[] = {
static const enum index item_ipv6_frag_ext[] = {
ITEM_IPV6_FRAG_EXT_NEXT_HDR,
ITEM_IPV6_FRAG_EXT_FRAG_DATA,
+ ITEM_IPV6_FRAG_EXT_ID,
ITEM_NEXT,
ZERO,
};
@@ -2466,6 +2470,13 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4,
hdr.type_of_service)),
},
+ [ITEM_IPV4_ID] = {
+ .name = "packet_id",
+ .help = "fragment packet id",
+ .next = NEXT(item_ipv4, NEXT_ENTRY(UNSIGNED), item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv4,
+hdr.packet_id)),
+ },
[ITEM_IPV4_FRAGMENT_OFFSET] = {
.name = "fragment_offset",
.help = "fragmentation flags and fragment offset",
@@ -2969,12 +2980,20 @@ static const struct token token_list[] = {
},
[ITEM_IPV6_FRAG_EXT_FRAG_DATA] = {
.name = "frag_data",
- .help = "Fragment flags and offset",
+ .help = "fragment flags and offset",
.next = NEXT(item_ipv6_frag_ext, NEXT_ENTRY(UNSIGNED),
item_param),
.args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_frag_ext,
hdr.frag_data)),
},
+ [ITEM_IPV6_FRAG_EXT_ID] = {
+ .name = "packet_id",
+ .help = "fragment packet id",
+ .next = NEXT(item_ipv6_frag_ext, NEXT_ENTRY(UNSIGNED),
+item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_frag_ext,
+hdr.id)),
+ },
[ITEM_ICMP6] = {
.name = "icmp6",
.help = "match any ICMPv6 header",
--
2.20.1
[dpdk-dev] [PATCH v4 3/4] net/iavf: support RSS hash for IP fragment
New pattern and RSS hash flow parsing are added to handle fragmented
IPv4/IPv6 packet.
Signed-off-by: Ting Xu
Signed-off-by: Jeff Guo
---
drivers/net/iavf/iavf_generic_flow.c | 24
drivers/net/iavf/iavf_generic_flow.h | 3 +
drivers/net/iavf/iavf_hash.c | 83
3 files changed, 100 insertions(+), 10 deletions(-)
diff --git a/drivers/net/iavf/iavf_generic_flow.c
b/drivers/net/iavf/iavf_generic_flow.c
index 8635ff83ca..242bb4abc5 100644
--- a/drivers/net/iavf/iavf_generic_flow.c
+++ b/drivers/net/iavf/iavf_generic_flow.c
@@ -219,6 +219,30 @@ enum rte_flow_item_type iavf_pattern_eth_qinq_ipv6[] = {
RTE_FLOW_ITEM_TYPE_END,
};
+enum rte_flow_item_type iavf_pattern_eth_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+enum rte_flow_item_type iavf_pattern_eth_vlan_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+enum rte_flow_item_type iavf_pattern_eth_qinq_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
enum rte_flow_item_type iavf_pattern_eth_ipv6_udp[] = {
RTE_FLOW_ITEM_TYPE_ETH,
RTE_FLOW_ITEM_TYPE_IPV6,
diff --git a/drivers/net/iavf/iavf_generic_flow.h
b/drivers/net/iavf/iavf_generic_flow.h
index 005eeb3553..32932557ca 100644
--- a/drivers/net/iavf/iavf_generic_flow.h
+++ b/drivers/net/iavf/iavf_generic_flow.h
@@ -203,6 +203,9 @@ extern enum rte_flow_item_type
iavf_pattern_eth_qinq_ipv4_icmp[];
extern enum rte_flow_item_type iavf_pattern_eth_ipv6[];
extern enum rte_flow_item_type iavf_pattern_eth_vlan_ipv6[];
extern enum rte_flow_item_type iavf_pattern_eth_qinq_ipv6[];
+extern enum rte_flow_item_type iavf_pattern_eth_ipv6_frag_ext[];
+extern enum rte_flow_item_type iavf_pattern_eth_vlan_ipv6_frag_ext[];
+extern enum rte_flow_item_type iavf_pattern_eth_qinq_ipv6_frag_ext[];
extern enum rte_flow_item_type iavf_pattern_eth_ipv6_udp[];
extern enum rte_flow_item_type iavf_pattern_eth_vlan_ipv6_udp[];
extern enum rte_flow_item_type iavf_pattern_eth_qinq_ipv6_udp[];
diff --git a/drivers/net/iavf/iavf_hash.c b/drivers/net/iavf/iavf_hash.c
index d8d22f8009..5d3d62839b 100644
--- a/drivers/net/iavf/iavf_hash.c
+++ b/drivers/net/iavf/iavf_hash.c
@@ -112,6 +112,10 @@ iavf_hash_parse_pattern_action(struct iavf_adapter *ad,
FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_SRC) | \
FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_DST), {BUFF_NOUSED} }
+#define proto_hdr_ipv6_frag { \
+ VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG_PKID), {BUFF_NOUSED} }
+
#define proto_hdr_ipv6_with_prot { \
VIRTCHNL_PROTO_HDR_IPV6, \
FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_SRC) | \
@@ -190,6 +194,12 @@ struct virtchnl_proto_hdrs outer_ipv6_tmplt = {
{proto_hdr_eth, proto_hdr_svlan, proto_hdr_cvlan, proto_hdr_ipv6}
};
+struct virtchnl_proto_hdrs outer_ipv6_frag_tmplt = {
+ TUNNEL_LEVEL_OUTER, 5,
+ {proto_hdr_eth, proto_hdr_svlan, proto_hdr_cvlan,
+proto_hdr_ipv6, proto_hdr_ipv6_frag}
+};
+
struct virtchnl_proto_hdrs outer_ipv6_udp_tmplt = {
TUNNEL_LEVEL_OUTER, 5,
{proto_hdr_eth, proto_hdr_svlan, proto_hdr_cvlan,
@@ -303,7 +313,8 @@ struct virtchnl_proto_hdrs ipv4_ecpri_tmplt = {
/* rss type super set */
/* IPv4 outer */
-#define IAVF_RSS_TYPE_OUTER_IPV4 (ETH_RSS_ETH | ETH_RSS_IPV4)
+#define IAVF_RSS_TYPE_OUTER_IPV4 (ETH_RSS_ETH | ETH_RSS_IPV4 | \
+ETH_RSS_FRAG_IPV4)
#define IAVF_RSS_TYPE_OUTER_IPV4_UDP (IAVF_RSS_TYPE_OUTER_IPV4 | \
ETH_RSS_NONFRAG_IPV4_UDP)
#define IAVF_RSS_TYPE_OUTER_IPV4_TCP (IAVF_RSS_TYPE_OUTER_IPV4 | \
@@ -312,6 +323,8 @@ struct virtchnl_proto_hdrs ipv4_ecpri_tmplt = {
ETH_RSS_NONFRAG_IPV4_SCTP)
/* IPv6 outer */
#define IAVF_RSS_TYPE_OUTER_IPV6 (ETH_RSS_ETH | ETH_RSS_IPV6)
+#define IAVF_RSS_TYPE_OUTER_IPV6_FRAG (IAVF_RSS_TYPE_OUTER_IPV6 | \
+ETH_RSS_FRAG_IPV6)
#define IAVF_RSS_TYPE_OUTER_IPV6_UDP (IAVF_RSS_TYPE_OUTER_IPV6 | \
ETH_RSS_NONFRAG_IPV6_UDP)
#define IAVF_RSS_TYPE_OUTER_IPV6_TCP (IAVF_RSS_TYPE_OUTER_IPV6 | \
@@ -330,6 +343,8 @@ struct virtchnl_proto_hdrs ipv4_ecpri_tmplt = {
/* VLAN IPv6 */
#define IAVF_RSS_TYPE_VLAN_IPV6(IAVF_RSS_TYPE_OUTER_IPV6 | \
ETH_RSS_S_VLAN | ETH_RSS_C_VLAN)
+#define IAVF_RSS_TYPE_VLAN_IPV6_FRAG (IAVF_RSS_TYPE_OUTER_IPV6_FRAG | \
+
Re: [dpdk-dev] [PATCH v2 1/2] ethdev: add packet integrity checks
Hi Ferruh, > -Original Message- > From: Ferruh Yigit > Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks > > On 4/13/2021 8:12 AM, Ori Kam wrote: > > Hi Ferruh, > > > >> -Original Message- > >> From: Ferruh Yigit > >> Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks > >> > >> On 4/12/2021 8:26 PM, Ori Kam wrote: > >>> Hi Ferruh, > >>> > -Original Message- > From: Ferruh Yigit > Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks > > On 4/11/2021 6:34 PM, Gregory Etelson wrote: > > From: Ori Kam > > > > Currently, DPDK application can offload the checksum check, > > and report it in the mbuf. > > > > However, as more and more applications are offloading some or all > > logic and action to the HW, there is a need to check the packet > > integrity so the right decision can be taken. > > > > The application logic can be positive meaning if the packet is > > valid jump / do actions, or negative if packet is not valid > > jump to SW / do actions (like drop) a, and add default flow > > (match all in low priority) that will direct the miss packet > > to the miss path. > > > > Since currenlty rte_flow works in positive way the assumtion is > > that the postive way will be the common way in this case also. > > > > When thinking what is the best API to implement such feature, > > we need to considure the following (in no specific order): > > 1. API breakage. > > 2. Simplicity. > > 3. Performance. > > 4. HW capabilities. > > 5. rte_flow limitation. > > 6. Flexability. > > > > First option: Add integrity flags to each of the items. > > For example add checksum_ok to ipv4 item. > > > > Pros: > > 1. No new rte_flow item. > > 2. Simple in the way that on each item the app can see > > what checks are available. > > > > Cons: > > 1. API breakage. > > 2. increase number of flows, since app can't add global rule and > > must have dedicated flow for each of the flow combinations, for > >> example > > matching on icmp traffic or UDP/TCP traffic with IPv4 / IPv6 will > > result in 5 flows. > > > > Second option: dedicated item > > > > Pros: > > 1. No API breakage, and there will be no for some time due to having > > extra space. (by using bits) > > 2. Just one flow to support the icmp or UDP/TCP traffic with IPv4 / > > IPv6. > > 3. Simplicity application can just look at one place to see all possible > > checks. > > 4. Allow future support for more tests. > > > > Cons: > > 1. New item, that holds number of fields from different items. > > > > For starter the following bits are suggested: > > 1. packet_ok - means that all HW checks depending on packet layer have > > passed. This may mean that in some HW such flow should be splited > to > > number of flows or fail. > > 2. l2_ok - all check flor layer 2 have passed. > > 3. l3_ok - all check flor layer 2 have passed. If packet doens't have > > l3 layer this check shoudl fail. > > 4. l4_ok - all check flor layer 2 have passed. If packet doesn't > > have l4 layer this check should fail. > > 5. l2_crc_ok - the layer 2 crc is O.K. it is possible that the crc will > > be O.K. but the l3_ok will be 0. it is not possible that > > l2_crc_ok will > > be 0 and the l3_ok will be 0. > > 6. ipv4_csum_ok - IPv4 checksum is O.K. > > 7. l4_csum_ok - layer 4 checksum is O.K. > > 8. l3_len_OK - check that the reported layer 3 len is smaller than the > > packet len. > > > > Example of usage: > > 1. check packets from all possible layers for integrity. > > flow create integrity spec packet_ok = 1 mask packet_ok = 1 . > > > > 2. Check only packet with layer 4 (UDP / TCP) > > flow create integrity spec l3_ok = 1, l4_ok = 1 mask l3_ok = 1 > > l4_ok = > 1 > > > > Hi Ori, > > Is the intention of the API just filtering, like apply some action to the > packets based on their integration status. Like drop packets their l2_crc > checksum failed? Here configuration is done by existing offload APIs. > > Or is the intention to configure the integration check on NIC, like to > say > enable layer 2 checks, and do the action based on integration check > status. > > >>> If I understand your question the first case is the one that this patch is > >> targeting. > >>> meaning based on those bits route/apply actions to the packet while still > >>> in > >> the > >>> HW. > >>> > >>> This is not design to enable the queue status bits. > >>> In the use case suggestion by this patch, just like you said the app > >>> can decide to drop the packet before arriv
Re: [dpdk-dev] [PATCH 0/4] l3fwd improvements
Hello, This patch series targeted to improve L3fwd example. Performance gain was observed on N1SDP platform. It would be good if you can run this series on your platforms and see if there is any performance impact. Thanks, Ruifeng > -Original Message- > From: Ruifeng Wang > Sent: Thursday, March 18, 2021 6:26 PM > To: jer...@marvell.com; hemant.agra...@nxp.com; ferruh.yi...@intel.com; > tho...@monjalon.net; david.march...@redhat.com > Cc: dev@dpdk.org; nd ; Honnappa Nagarahalli > ; Ruifeng Wang > > Subject: [PATCH 0/4] l3fwd improvements > > This series of patches include changes to l3fwd example application. > Some improvements are made for better usage of CPU cycles and memory. > > Ruifeng Wang (4): > examples/l3fwd: tune prefetch for better performance > examples/l3fwd: eliminate unnecessary calculations > examples/l3fwd: eliminate unnecessary reloads in loop > examples/l3fwd: make data struct to be memory efficient > > examples/l3fwd/l3fwd.h | 12 ++-- > examples/l3fwd/l3fwd_common.h | 4 ++-- > examples/l3fwd/l3fwd_em.c | 6 +++--- > examples/l3fwd/l3fwd_lpm.c | 16 +--- > examples/l3fwd/l3fwd_lpm_neon.h | 20 ++-- > 5 files changed, 30 insertions(+), 28 deletions(-) > > -- > 2.25.1
Re: [dpdk-dev] [PATCH v2 1/2] ethdev: add packet integrity checks
On 4/13/2021 9:18 AM, Ori Kam wrote: Hi Ferruh, -Original Message- From: Ferruh Yigit Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks On 4/13/2021 8:12 AM, Ori Kam wrote: Hi Ferruh, -Original Message- From: Ferruh Yigit Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks On 4/12/2021 8:26 PM, Ori Kam wrote: Hi Ferruh, -Original Message- From: Ferruh Yigit Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks On 4/11/2021 6:34 PM, Gregory Etelson wrote: From: Ori Kam Currently, DPDK application can offload the checksum check, and report it in the mbuf. However, as more and more applications are offloading some or all logic and action to the HW, there is a need to check the packet integrity so the right decision can be taken. The application logic can be positive meaning if the packet is valid jump / do actions, or negative if packet is not valid jump to SW / do actions (like drop) a, and add default flow (match all in low priority) that will direct the miss packet to the miss path. Since currenlty rte_flow works in positive way the assumtion is that the postive way will be the common way in this case also. When thinking what is the best API to implement such feature, we need to considure the following (in no specific order): 1. API breakage. 2. Simplicity. 3. Performance. 4. HW capabilities. 5. rte_flow limitation. 6. Flexability. First option: Add integrity flags to each of the items. For example add checksum_ok to ipv4 item. Pros: 1. No new rte_flow item. 2. Simple in the way that on each item the app can see what checks are available. Cons: 1. API breakage. 2. increase number of flows, since app can't add global rule and must have dedicated flow for each of the flow combinations, for example matching on icmp traffic or UDP/TCP traffic with IPv4 / IPv6 will result in 5 flows. Second option: dedicated item Pros: 1. No API breakage, and there will be no for some time due to having extra space. (by using bits) 2. Just one flow to support the icmp or UDP/TCP traffic with IPv4 / IPv6. 3. Simplicity application can just look at one place to see all possible checks. 4. Allow future support for more tests. Cons: 1. New item, that holds number of fields from different items. For starter the following bits are suggested: 1. packet_ok - means that all HW checks depending on packet layer have passed. This may mean that in some HW such flow should be splited to number of flows or fail. 2. l2_ok - all check flor layer 2 have passed. 3. l3_ok - all check flor layer 2 have passed. If packet doens't have l3 layer this check shoudl fail. 4. l4_ok - all check flor layer 2 have passed. If packet doesn't have l4 layer this check should fail. 5. l2_crc_ok - the layer 2 crc is O.K. it is possible that the crc will be O.K. but the l3_ok will be 0. it is not possible that l2_crc_ok will be 0 and the l3_ok will be 0. 6. ipv4_csum_ok - IPv4 checksum is O.K. 7. l4_csum_ok - layer 4 checksum is O.K. 8. l3_len_OK - check that the reported layer 3 len is smaller than the packet len. Example of usage: 1. check packets from all possible layers for integrity. flow create integrity spec packet_ok = 1 mask packet_ok = 1 . 2. Check only packet with layer 4 (UDP / TCP) flow create integrity spec l3_ok = 1, l4_ok = 1 mask l3_ok = 1 l4_ok = 1 Hi Ori, Is the intention of the API just filtering, like apply some action to the packets based on their integration status. Like drop packets their l2_crc checksum failed? Here configuration is done by existing offload APIs. Or is the intention to configure the integration check on NIC, like to say enable layer 2 checks, and do the action based on integration check status. If I understand your question the first case is the one that this patch is targeting. meaning based on those bits route/apply actions to the packet while still in the HW. This is not design to enable the queue status bits. In the use case suggestion by this patch, just like you said the app can decide to drop the packet before arriving to the queue, application may also use the mark + queue action to mark to the SW what is the issue with this packet. I'm not sure I understand your comment about "here configuration is done by existing offload API" do you mean like the drop / jump to table / any other rte_flow action? I am asking because difference between device configuration and packet filtering seems getting more blurred in the flow API. Currently L4 checksum offload is requested by application via setting 'DEV_RX_OFFLOAD_TCP_CKSUM' (UDP/SCTP/...) offload flags. This is the way to configure HW. Is the intention of this patch doing packet filtering after device configured with above offload API? Or is the intention HW to be configured via flow API, like if "l4_ok = 1" is set in the rule, will i
Re: [dpdk-dev] [PATCH] eal/linux: add operation LOCK_NB to flock()
On Thu, Mar 25, 2021 at 4:25 PM wrote:
>
> From: Tonghao Zhang
ping
> The hugepage of different size, 2MB, 1GB may be mounted on
> the same directory (e.g /dev/hugepages). Then dpdk
> primary process will be blocked. To address this issue,
> add the LOCK_NB flags to flock().
>
> $ cat /proc/mounts
> ...
> none /dev/hugepages hugetlbfs rw,seclabel,relatime,pagesize=1024M 0 0
> none /dev/hugepages hugetlbfs rw,seclabel,relatime,pagesize=2M 0 0
>
> Add more details for err logs.
>
> Signed-off-by: Tonghao Zhang
> ---
> lib/librte_eal/linux/eal_hugepage_info.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_eal/linux/eal_hugepage_info.c
> b/lib/librte_eal/linux/eal_hugepage_info.c
> index d97792cadeb6..1ff76e539053 100644
> --- a/lib/librte_eal/linux/eal_hugepage_info.c
> +++ b/lib/librte_eal/linux/eal_hugepage_info.c
> @@ -451,9 +451,12 @@ hugepage_info_init(void)
> hpi->lock_descriptor = open(hpi->hugedir, O_RDONLY);
>
> /* if blocking lock failed */
> - if (flock(hpi->lock_descriptor, LOCK_EX) == -1) {
> + if (flock(hpi->lock_descriptor, LOCK_EX | LOCK_NB) == -1) {
> RTE_LOG(CRIT, EAL,
> - "Failed to lock hugepage directory!\n");
> + "Failed to lock hugepage directory! "
> + "The hugepage dir (%s) was locked by "
> + "other processes or self twice.\n",
> + hpi->hugedir);
> break;
> }
> /* clear out the hugepages dir from unused pages */
> --
> 2.27.0
>
--
Best regards, Tonghao
Re: [dpdk-dev] [PATCH] net/hns3: support trace Rx/Tx burst function
On 4/9/2021 11:26 AM, Min Hu (Connor) wrote: From: Chengwen Feng This patch adds debug info for Rx/Tx burst function which was choosing. Signed-off-by: Chengwen Feng Signed-off-by: Min Hu (Connor) Applied to dpdk-next-net/main, thanks.
Re: [dpdk-dev] [PATCH v5 2/4] vhost: add support for packed ring in async vhost
On 4/12/21 1:34 PM, Cheng Jiang wrote:
> For now async vhost data path only supports split ring structure. In
> order to make async vhost compatible with virtio 1.1 spec this patch
> enables packed ring in async vhost data path.
>
> Signed-off-by: Cheng Jiang
> ---
> lib/librte_vhost/rte_vhost_async.h | 1 +
> lib/librte_vhost/vhost.c | 27 +-
> lib/librte_vhost/vhost.h | 7 +-
> lib/librte_vhost/virtio_net.c | 438 +++--
> 4 files changed, 448 insertions(+), 25 deletions(-)
>
> diff --git a/lib/librte_vhost/rte_vhost_async.h
> b/lib/librte_vhost/rte_vhost_async.h
> index c855ff875..6faa31f5a 100644
> --- a/lib/librte_vhost/rte_vhost_async.h
> +++ b/lib/librte_vhost/rte_vhost_async.h
> @@ -89,6 +89,7 @@ struct rte_vhost_async_channel_ops {
> struct async_inflight_info {
> struct rte_mbuf *mbuf;
> uint16_t descs; /* num of descs inflight */
> + uint16_t nr_buffers; /* num of buffers inflight for packed ring */
> };
>
> /**
> diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
> index a70fe01d8..8c9935c0f 100644
> --- a/lib/librte_vhost/vhost.c
> +++ b/lib/librte_vhost/vhost.c
> @@ -342,15 +342,21 @@ vhost_free_async_mem(struct vhost_virtqueue *vq)
> {
> if (vq->async_pkts_info)
> rte_free(vq->async_pkts_info);
> - if (vq->async_descs_split)
> + if (vq->async_buffers_packed) {
> + rte_free(vq->async_buffers_packed);
> + vq->async_buffers_packed = NULL;
> + }
> + if (vq->async_descs_split) {
You can remove the check, rte_free is safe with NULL pointers.
You can do the same for the other ones in this function.
> rte_free(vq->async_descs_split);
> + vq->async_descs_split = NULL;
> + }
> +
> if (vq->it_pool)
> rte_free(vq->it_pool);
> if (vq->vec_pool)
> rte_free(vq->vec_pool);
>
> vq->async_pkts_info = NULL;
> - vq->async_descs_split = NULL;
> vq->it_pool = NULL;
> vq->vec_pool = NULL;
> }
> @@ -1627,9 +1633,9 @@ int rte_vhost_async_channel_register(int vid, uint16_t
> queue_id,
> return -1;
>
> /* packed queue is not supported */
> - if (unlikely(vq_is_packed(dev) || !f.async_inorder)) {
> + if (unlikely(!f.async_inorder)) {
> VHOST_LOG_CONFIG(ERR,
> - "async copy is not supported on packed queue or
> non-inorder mode "
> + "async copy is not supported on non-inorder mode "
> "(vid %d, qid: %d)\n", vid, queue_id);
> return -1;
> }
> @@ -1667,11 +1673,18 @@ int rte_vhost_async_channel_register(int vid,
> uint16_t queue_id,
> vq->vec_pool = rte_malloc_socket(NULL,
> VHOST_MAX_ASYNC_VEC * sizeof(struct iovec),
> RTE_CACHE_LINE_SIZE, node);
> - vq->async_descs_split = rte_malloc_socket(NULL,
> + if (vq_is_packed(dev)) {
> + vq->async_buffers_packed = rte_malloc_socket(NULL,
> + vq->size * sizeof(struct vring_used_elem_packed),
> + RTE_CACHE_LINE_SIZE, node);
> + } else {
> + vq->async_descs_split = rte_malloc_socket(NULL,
> vq->size * sizeof(struct vring_used_elem),
> RTE_CACHE_LINE_SIZE, node);
> - if (!vq->async_descs_split || !vq->async_pkts_info ||
> - !vq->it_pool || !vq->vec_pool) {
> + }
> +
> + if (!vq->async_buffers_packed || !vq->async_descs_split ||
> + !vq->async_pkts_info || !vq->it_pool || !vq->vec_pool) {
> vhost_free_async_mem(vq);
> VHOST_LOG_CONFIG(ERR,
> "async register failed: cannot allocate memory
> for vq data "
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> index f628714c2..fe131ae8f 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -201,9 +201,14 @@ struct vhost_virtqueue {
> uint16_tasync_pkts_idx;
> uint16_tasync_pkts_inflight_n;
> uint16_tasync_last_pkts_n;
> - struct vring_used_elem *async_descs_split;
> + union {
> + struct vring_used_elem *async_descs_split;
> + struct vring_used_elem_packed *async_buffers_packed;
> + };
> uint16_t async_desc_idx;
> + uint16_t async_packed_buffer_idx;
Don't dupplicate variable names, async_desc_idx can be reused for packed
ring. Also, they are representing the same thing, why use desc in one
case and buffer in the other?
> uint16_t last_async_desc_idx;
> + uint16_t last_async_buffer_idx;
Same remark here.
> /* vq async features */
> boolasync_inorder;
> diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
> index c43ab0093..410be9678 100644
> --- a/lib/librte_vhost/virtio_net.c
> +++ b/lib/librte_vhost/virtio_net.c
> @
Re: [dpdk-dev] [PATCH v2 1/5] ethdev: modify rte API for single flow dump
On Tue, Apr 6, 2021 at 11:09 PM Haifei Luo wrote: > > Previous implementations support dump all the flows. Add new arg > rte_flow in rte_flow_dev_dump to dump one flow. > > Signed-off-by: Haifei Luo > --- > app/test-pmd/config.c| 2 +- > doc/guides/nics/mlx5.rst | 9 ++--- > doc/guides/prog_guide/rte_flow.rst | 24 > drivers/net/mlx5/linux/mlx5_socket.c | 2 +- > drivers/net/mlx5/mlx5.h | 4 ++-- > drivers/net/mlx5/mlx5_flow.c | 9 ++--- > drivers/net/octeontx2/otx2_flow.c| 9 - > lib/librte_ethdev/rte_flow.c | 5 +++-- > lib/librte_ethdev/rte_flow.h | 5 - > lib/librte_ethdev/rte_flow_driver.h | 1 + > 10 files changed, 56 insertions(+), 14 deletions(-) > Acked-by: Ajit Khaparde
Re: [dpdk-dev] [PATCH v2] ethdev: add sanity checks in control APIs
On 4/13/21 6:22 AM, Min Hu (Connor) wrote:
> This patch adds more sanity checks in control path APIs.
>
> Fixes: 214ed1acd125 ("ethdev: add iterator to match devargs input")
> Fixes: 3d98f921fbe9 ("ethdev: unify prefix for static functions and
> variables")
> Fixes: 0366137722a0 ("ethdev: check for invalid device name")
> Fixes: d948f596fee2 ("ethdev: fix port data mismatched in multiple process
> model")
> Fixes: 5b7ba31148a8 ("ethdev: add port ownership")
> Fixes: f8244c6399d9 ("ethdev: increase port id range")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Min Hu (Connor)
Many thanks for working on it. Few notes below.
[snip]
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 6b5cfd6..e1655b5 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -678,6 +684,9 @@ rte_eth_dev_owner_set(const uint16_t port_id,
> {
> int ret;
>
> + if (owner == NULL)
> + return -EINVAL;
> +
Here and in many-many cases below I think the order of checks
is important in cases when different error codes are returned.
When there is no any very good reasons why arguments should
be checked in different order, arguments should be checked in
order specified in function prototype. In this cases (and many
cases below), port_id should be checked first.
In this particular case it means that the pointer check
should be done in a static helper function.
One more point is error logging in the case of failure.
Right now I'd use RTE_ETHDEV_LOG(ERR, ...). May be later we'll
find out that some of messages should be made INFO or DEBUG.
Something like:
RTE_ETHDEV_LOG(ERR, "Failed to set ethdev port %u owner to NULL\n",
port_id);
I'm not 100% sure in format, but my requirements are:
- log messages should be unique
- log messages should be human readable (i.e. I'd avoid
usage of function name)
- log messages should provide enough information to understand
what went wrong and provide context (basically it correlates
with uniqueness requirement)
@Thomas, @Ferruh, what do you think? It would be good if we
reach an argement before mass changes are done?
> @@ -2491,6 +2515,12 @@ rte_eth_tx_done_cleanup(uint16_t port_id, uint16_t
> queue_id, uint32_t free_cnt)
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_done_cleanup, -ENOTSUP);
>
> + if (queue_id >= dev->data->nb_tx_queues) {
> + RTE_ETHDEV_LOG(ERR, "Queue id should be < %u.",
> +dev->data->nb_tx_queues);
> + return -EINVAL;
> + }
> +
I'm not 100% sure that it is a control path.
> /* Call driver to free pending mbufs. */
> ret = (*dev->dev_ops->tx_done_cleanup)(dev->data->tx_queues[queue_id],
> free_cnt);
[snip]
[dpdk-dev] [PATCH] devtools: skip removed DLB driver in ABI check
The eventdev driver DLB was removed in DPDK 21.05,
breaking the ABI check.
The exception was agreed so we just need to skip this check.
Note: complete removal of a driver cannot be ignored
in devtools/libabigail.abignore, so the script must be patched.
Fixes: 698fa829415d ("event/dlb: remove driver")
Reported-by: David Marchand
Signed-off-by: Thomas Monjalon
---
This should have been done as part of removing the driver.
The CI is currently broken, so it should be merged today.
---
devtools/check-abi.sh | 4
1 file changed, 4 insertions(+)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index 9835e346da..ca523eb94c 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -44,6 +44,10 @@ for dump in $(find $refdir -name "*.dump"); do
echo "Skipped glue library $name."
continue
fi
+ if grep -qE "\&2
--
2.31.1
Re: [dpdk-dev] [PATCH] net/virtio: fix vhost_kernel_set_owner for multi-queue devices
Hi Thierry,
On 4/8/21 2:37 PM, Thierry Herbelot wrote:
> Restore the original code, where VHOST_SET_OWNER is applied to
> all vhostfds of the device.
>
> Fixes: 06856cabb89b0 ("net/virtio: add virtio-user ops to set owner")
> Cc: Maxime Coquelin
> Cc: Chenbo Xia
> Signed-off-by: Thierry Herbelot
> ---
> drivers/net/virtio/virtio_user/vhost_kernel.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio/virtio_user/vhost_kernel.c
> b/drivers/net/virtio/virtio_user/vhost_kernel.c
> index 768db55a6c1f..58e66bb7b4ae 100644
> --- a/drivers/net/virtio/virtio_user/vhost_kernel.c
> +++ b/drivers/net/virtio/virtio_user/vhost_kernel.c
> @@ -101,9 +101,20 @@ vhost_kernel_ioctl(int fd, uint64_t request, void *arg)
> static int
> vhost_kernel_set_owner(struct virtio_user_dev *dev)
> {
> + int ret;
> + uint32_t i;
> struct vhost_kernel_data *data = dev->backend_data;
>
> - return vhost_kernel_ioctl(data->vhostfds[0], VHOST_SET_OWNER, NULL);
> + for (i = 0; i < dev->max_queue_pairs; ++i) {
> + if (data->vhostfds[i] < 0)
> + continue;
> +
> + ret = vhost_kernel_ioctl(data->vhostfds[i], VHOST_SET_OWNER,
> NULL);
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> }
>
> static int
>
Thanks for the fix, we indeed have to set owner for all the queue pairs.
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v1] bus/auxiliary: introduce auxiliary bus
I would like to Cc those who are interested in the auxiliary bus, but it's difficult to know who will implement it. Can we expect some reviews? 13/04/2021 05:23, Xueming Li: > Auxiliary [1] provides a way to split function into child-devices > representing sub-domains of functionality. Each auxiliary_device > represents a part of its parent functionality. > > Auxiliary device is identified by unique device name, sysfs path: > /sys/bus/auxiliary/devices/ > > [1] kernel auxiliary bus document: > https://www.kernel.org/doc/html/latest/driver-api/auxiliary_bus.html > > Signed-off-by: Xueming Li
Re: [dpdk-dev] [PATCH] examples/vhost: fix ioat ring space in callbacks
On 4/7/21 9:54 AM, Hu, Jiayu wrote:
> Hi Maxime,
>
>> -Original Message-
>> From: Maxime Coquelin
>> Sent: Wednesday, April 7, 2021 3:48 PM
>> To: Jiang, Cheng1 ; Xia, Chenbo
>> ; Thomas Monjalon
>> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
>> ; Wang, Yinan ;
>> sta...@dpdk.org
>> Subject: Re: [PATCH] examples/vhost: fix ioat ring space in callbacks
>>
>>
>>
>> On 3/17/21 6:40 AM, Cheng Jiang wrote:
>>> We use ioat ring space for determining if ioat callbacks can enqueue a
>>> packet to ioat device. But there is one slot can't be used in ioat
>>> ring due to the ioat driver design, so we need to reduce one slot in
>>> ioat ring to prevent ring size mismatch in ioat callbacks.
>>>
>>> Fixes: 2aa47e94bfb2 ("examples/vhost: add ioat ring space count and
>> check")
>>> Cc: sta...@dpdk.org
>>>
>>> Signed-off-by: Cheng Jiang
>>> ---
>>> examples/vhost/ioat.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/examples/vhost/ioat.c b/examples/vhost/ioat.c
>>> index 60b73be93..9cb5e0d50 100644
>>> --- a/examples/vhost/ioat.c
>>> +++ b/examples/vhost/ioat.c
>>> @@ -113,7 +113,7 @@ open_ioat(const char *value)
>>> goto out;
>>> }
>>> rte_rawdev_start(dev_id);
>>> - cb_tracker[dev_id].ioat_space = IOAT_RING_SIZE;
>>> + cb_tracker[dev_id].ioat_space = IOAT_RING_SIZE - 1;
>>
>> That really comforts me in thinking we need a generic abstraction for
>> DMA devices. How is the application developer supposed to know that
>> the DMA driver has such weird limitations?
>>
>> Can the driver be fixed to have a proper behavior?
>
> Here is the patch of providing capacity check API for DMA:
> http://patches.dpdk.org/project/dpdk/patch/20210318182042.43658-6-bruce.richard...@intel.com/
OK, thanks for the pointer.
While this new API is being reviewed, and for LTS, let's pick your
patch. As soon as Bruce patch is merged, please send a new patch on top
to make use of this API.
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
> Thanks,
> Jiayu
>>
>>> dma_info->nr++;
>>> i++;
>>> }
>>>
>
Re: [dpdk-dev] [PATCH v7 2/3] event/octeontx2: support crypto adapter forward mode
On Tue, Apr 13, 2021 at 03:34:50AM +, Gujjar, Abhinandan S wrote:
>
>
> > -Original Message-
> > From: Shijith Thotton
> > Sent: Monday, April 12, 2021 1:14 PM
> > To: dev@dpdk.org
> > Cc: Shijith Thotton ; tho...@monjalon.net;
> > jer...@marvell.com; Gujjar, Abhinandan S ;
> > hemant.agra...@nxp.com; nipun.gu...@nxp.com;
> > sachin.sax...@oss.nxp.com; ano...@marvell.com; ma...@nvidia.com;
> > Zhang, Roy Fan ; g.si...@nxp.com; Carrillo, Erik
> > G ; Jayatheerthan, Jay
> > ; pbhagavat...@marvell.com; Van Haaren,
> > Harry ; Akhil Goyal
> > Subject: [PATCH v7 2/3] event/octeontx2: support crypto adapter forward
> > mode
> >
> > Advertise crypto adapter forward mode capability and set crypto adapter
> > enqueue function in driver.
> >
> > Signed-off-by: Shijith Thotton
> > ---
> > drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 42 ++
> > drivers/event/octeontx2/otx2_evdev.c | 5 +-
> > .../event/octeontx2/otx2_evdev_crypto_adptr.c | 3 +- ...dptr_dp.h =>
> > otx2_evdev_crypto_adptr_rx.h} | 6 +-
> > .../octeontx2/otx2_evdev_crypto_adptr_tx.h| 83
> > +++
> > drivers/event/octeontx2/otx2_worker.h | 2 +-
> > drivers/event/octeontx2/otx2_worker_dual.h| 2 +-
> > 7 files changed, 122 insertions(+), 21 deletions(-) rename
> > drivers/event/octeontx2/{otx2_evdev_crypto_adptr_dp.h =>
> > otx2_evdev_crypto_adptr_rx.h} (93%) create mode 100644
> > drivers/event/octeontx2/otx2_evdev_crypto_adptr_tx.h
> >
> > diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
> > b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
> > index cec20b5c6..4808dca64 100644
> > --- a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
> > +++ b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
> > @@ -7,6 +7,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "otx2_cryptodev.h"
> > #include "otx2_cryptodev_capabilities.h"
> > @@ -434,15 +435,28 @@ sym_session_configure(int driver_id, struct
> > rte_crypto_sym_xform *xform,
> > return -ENOTSUP;
> > }
> >
> > -static __rte_always_inline void __rte_hot
> > +static __rte_always_inline int32_t __rte_hot
> > otx2_ca_enqueue_req(const struct otx2_cpt_qp *qp,
> > struct cpt_request_info *req,
> > void *lmtline,
> > + struct rte_crypto_op *op,
> > uint64_t cpt_inst_w7)
> > {
> > + union rte_event_crypto_metadata *m_data;
> > union cpt_inst_s inst;
> > uint64_t lmt_status;
> >
> > + if (op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
> > + m_data = rte_cryptodev_sym_session_get_user_data(
> > + op->sym->session);
> m_data == NULL check & freeing memory is missing. Similar to what you have
> done in otx2_ca_enq().
> With this change you can add Acked-by: abhinandan.guj...@intel.com
>
Thanks. I will send next version with the change.
> > + else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
> > +op->private_data_offset)
> > + m_data = (union rte_event_crypto_metadata *)
> > +((uint8_t *)op +
> > + op->private_data_offset);
> > + else
> > + return -EINVAL;
> > +
> > inst.u[0] = 0;
> > inst.s9x.res_addr = req->comp_baddr;
> > inst.u[2] = 0;
> > @@ -453,12 +467,11 @@ otx2_ca_enqueue_req(const struct otx2_cpt_qp
> > *qp,
> > inst.s9x.ei2 = req->ist.ei2;
> > inst.s9x.ei3 = cpt_inst_w7;
> >
> > - inst.s9x.qord = 1;
> > - inst.s9x.grp = qp->ev.queue_id;
> > - inst.s9x.tt = qp->ev.sched_type;
> > - inst.s9x.tag = (RTE_EVENT_TYPE_CRYPTODEV << 28) |
> > - qp->ev.flow_id;
> > - inst.s9x.wq_ptr = (uint64_t)req >> 3;
> > + inst.u[2] = (((RTE_EVENT_TYPE_CRYPTODEV << 28) |
> > + m_data->response_info.flow_id) |
> > +((uint64_t)m_data->response_info.sched_type << 32) |
> > +((uint64_t)m_data->response_info.queue_id << 34));
> > + inst.u[3] = 1 | (((uint64_t)req >> 3) << 3);
> > req->qp = qp;
> >
> > do {
> > @@ -475,22 +488,22 @@ otx2_ca_enqueue_req(const struct otx2_cpt_qp
> > *qp,
> > lmt_status = otx2_lmt_submit(qp->lf_nq_reg);
> > } while (lmt_status == 0);
> >
> > + return 0;
> > }
> >
> > static __rte_always_inline int32_t __rte_hot otx2_cpt_enqueue_req(const
> > struct otx2_cpt_qp *qp,
> > struct pending_queue *pend_q,
> > struct cpt_request_info *req,
> > +struct rte_crypto_op *op,
> > uint64_t cpt_inst_w7)
> > {
> > void *lmtline = qp->lmtline;
> > union cpt_inst_s inst;
> > uint64_t lmt_status;
> >
> > - if (qp->ca_enable) {
> > - otx2_ca_enqueue_req(qp, req, lmtline, cpt_inst_w7);
> > - return 0;
> > - }
> > + if (qp->ca_enable)
> > + return otx2_ca_enqueue_req(qp, req, lmtline, op,
> > cpt_inst_w7);
> >
> > if (unlikely(pend_q->pending_count >=
[dpdk-dev] [PATCH v4 0/3] support flow for IP fragment in ICE
Support RSS hash and FDIR for IP fragment packets in ICE PMD. v4: correct typo when define fragment v3: rebase code and fix some parsing issues. v2: add some input check Jeff Guo (3): net/ice/base: support IP fragment RSS and FDIR net/ice: support RSS hash for IP fragment net/ice: support FDIR for IP fragment packet drivers/net/ice/base/ice_fdir.c| 50 - drivers/net/ice/base/ice_fdir.h| 22 +- drivers/net/ice/base/ice_flow.c| 50 - drivers/net/ice/base/ice_flow.h| 5 +- drivers/net/ice/base/ice_type.h| 1 + drivers/net/ice/ice_fdir_filter.c | 116 ++--- drivers/net/ice/ice_generic_flow.c | 22 ++ drivers/net/ice/ice_generic_flow.h | 6 ++ drivers/net/ice/ice_hash.c | 48 ++-- 9 files changed, 293 insertions(+), 27 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH v4 2/3] net/ice: support RSS hash for IP fragment
New pattern and RSS hash flow parsing are added to handle fragmented
IPv4/IPv6 packet.
Signed-off-by: Jeff Guo
---
drivers/net/ice/ice_generic_flow.c | 21 +
drivers/net/ice/ice_generic_flow.h | 6
drivers/net/ice/ice_hash.c | 48 +-
3 files changed, 67 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ice/ice_generic_flow.c
b/drivers/net/ice/ice_generic_flow.c
index 8704812622..2389bc6637 100644
--- a/drivers/net/ice/ice_generic_flow.c
+++ b/drivers/net/ice/ice_generic_flow.c
@@ -212,6 +212,27 @@ enum rte_flow_item_type pattern_eth_qinq_ipv6[] = {
RTE_FLOW_ITEM_TYPE_IPV6,
RTE_FLOW_ITEM_TYPE_END,
};
+enum rte_flow_item_type pattern_eth_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+enum rte_flow_item_type pattern_eth_vlan_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+enum rte_flow_item_type pattern_eth_qinq_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
enum rte_flow_item_type pattern_eth_ipv6_udp[] = {
RTE_FLOW_ITEM_TYPE_ETH,
RTE_FLOW_ITEM_TYPE_IPV6,
diff --git a/drivers/net/ice/ice_generic_flow.h
b/drivers/net/ice/ice_generic_flow.h
index 9f422e5925..2afe719264 100644
--- a/drivers/net/ice/ice_generic_flow.h
+++ b/drivers/net/ice/ice_generic_flow.h
@@ -52,6 +52,7 @@
#define ICE_L2TPV3OIP_SESSION_ID BIT_ULL(43)
#define ICE_PFCP_SEID BIT_ULL(42)
#define ICE_PFCP_S_FIELD BIT_ULL(41)
+#define ICE_IP_PK_ID BIT_ULL(40)
/* input set */
@@ -69,11 +70,13 @@
#define ICE_INSET_IPV4_TOS (ICE_PROT_IPV4 | ICE_IP_TOS)
#define ICE_INSET_IPV4_PROTO (ICE_PROT_IPV4 | ICE_IP_PROTO)
#define ICE_INSET_IPV4_TTL (ICE_PROT_IPV4 | ICE_IP_TTL)
+#define ICE_INSET_IPV4_PKID(ICE_PROT_IPV4 | ICE_IP_PK_ID)
#define ICE_INSET_IPV6_SRC (ICE_PROT_IPV6 | ICE_IP_SRC)
#define ICE_INSET_IPV6_DST (ICE_PROT_IPV6 | ICE_IP_DST)
#define ICE_INSET_IPV6_NEXT_HDR(ICE_PROT_IPV6 | ICE_IP_PROTO)
#define ICE_INSET_IPV6_HOP_LIMIT (ICE_PROT_IPV6 | ICE_IP_TTL)
#define ICE_INSET_IPV6_TC (ICE_PROT_IPV6 | ICE_IP_TOS)
+#define ICE_INSET_IPV6_PKID(ICE_PROT_IPV6 | ICE_IP_PK_ID)
#define ICE_INSET_TCP_SRC_PORT (ICE_PROT_TCP | ICE_SPORT)
#define ICE_INSET_TCP_DST_PORT (ICE_PROT_TCP | ICE_DPORT)
@@ -202,6 +205,9 @@ extern enum rte_flow_item_type pattern_eth_qinq_ipv4_icmp[];
extern enum rte_flow_item_type pattern_eth_ipv6[];
extern enum rte_flow_item_type pattern_eth_vlan_ipv6[];
extern enum rte_flow_item_type pattern_eth_qinq_ipv6[];
+extern enum rte_flow_item_type pattern_eth_ipv6_frag_ext[];
+extern enum rte_flow_item_type pattern_eth_vlan_ipv6_frag_ext[];
+extern enum rte_flow_item_type pattern_eth_qinq_ipv6_frag_ext[];
extern enum rte_flow_item_type pattern_eth_ipv6_udp[];
extern enum rte_flow_item_type pattern_eth_vlan_ipv6_udp[];
extern enum rte_flow_item_type pattern_eth_qinq_ipv6_udp[];
diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
index 7d7e7052da..9df20df550 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -47,8 +47,10 @@
ETH_RSS_NONFRAG_IPV6_TCP | \
ETH_RSS_NONFRAG_IPV6_SCTP)
-#define VALID_RSS_IPV4 (ETH_RSS_IPV4 | VALID_RSS_IPV4_L4)
-#define VALID_RSS_IPV6 (ETH_RSS_IPV6 | VALID_RSS_IPV6_L4)
+#define VALID_RSS_IPV4 (ETH_RSS_IPV4 | ETH_RSS_FRAG_IPV4 | \
+VALID_RSS_IPV4_L4)
+#define VALID_RSS_IPV6 (ETH_RSS_IPV6 | ETH_RSS_FRAG_IPV6 | \
+VALID_RSS_IPV6_L4)
#define VALID_RSS_L3 (VALID_RSS_IPV4 | VALID_RSS_IPV6)
#define VALID_RSS_L4 (VALID_RSS_IPV4_L4 | VALID_RSS_IPV6_L4)
@@ -108,6 +110,7 @@ ice_hash_parse_pattern_action(struct ice_adapter *ad,
/* Rss configuration template */
struct ice_rss_hash_cfg ipv4_tmplt = {
ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG |
ICE_FLOW_SEG_HDR_IPV_OTHER,
ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV4,
ICE_RSS_OUTER_HEADERS,
@@ -146,6 +149,15 @@ struct ice_rss_hash_cfg ipv6_tmplt = {
0
};
+struct ice_rss_hash_cfg ipv6_frag_tmplt = {
+ ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV6 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG |
+ ICE_FLOW_SEG_HDR_IPV_OTHER,
+ ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV6,
+ ICE_RSS_ANY_HEADERS,
+ 0
+};
+
struct ice_rss_hash_cfg
[dpdk-dev] [PATCH v4 3/3] net/ice: support FDIR for IP fragment packet
New FDIR parsing are added to handle the fragmented IPv4/IPv6 packet.
Signed-off-by: Jeff Guo
Signed-off-by: Ting Xu
---
drivers/net/ice/ice_fdir_filter.c | 116 ++---
drivers/net/ice/ice_generic_flow.c | 1 +
2 files changed, 106 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ice/ice_fdir_filter.c
b/drivers/net/ice/ice_fdir_filter.c
index 92e18d59cc..8158f75f05 100644
--- a/drivers/net/ice/ice_fdir_filter.c
+++ b/drivers/net/ice/ice_fdir_filter.c
@@ -24,7 +24,7 @@
#define ICE_FDIR_INSET_ETH_IPV4 (\
ICE_FDIR_INSET_ETH | \
ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | ICE_INSET_IPV4_TOS | \
- ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO)
+ ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO | ICE_INSET_IPV4_PKID)
#define ICE_FDIR_INSET_ETH_IPV4_UDP (\
ICE_FDIR_INSET_ETH_IPV4 | \
@@ -41,7 +41,8 @@
#define ICE_FDIR_INSET_ETH_IPV6 (\
ICE_INSET_DMAC | \
ICE_INSET_IPV6_SRC | ICE_INSET_IPV6_DST | ICE_INSET_IPV6_TC | \
- ICE_INSET_IPV6_HOP_LIMIT | ICE_INSET_IPV6_NEXT_HDR)
+ ICE_INSET_IPV6_HOP_LIMIT | ICE_INSET_IPV6_NEXT_HDR | \
+ ICE_INSET_IPV6_PKID)
#define ICE_FDIR_INSET_ETH_IPV6_UDP (\
ICE_FDIR_INSET_ETH_IPV6 | \
@@ -56,7 +57,8 @@
ICE_INSET_SCTP_SRC_PORT | ICE_INSET_SCTP_DST_PORT)
#define ICE_FDIR_INSET_IPV4 (\
- ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST)
+ ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | \
+ ICE_INSET_IPV4_PKID)
#define ICE_FDIR_INSET_IPV4_TCP (\
ICE_FDIR_INSET_IPV4 | \
@@ -95,6 +97,7 @@ static struct ice_pattern_match_item ice_fdir_pattern_list[]
= {
{pattern_eth_ipv4_tcp,
ICE_FDIR_INSET_ETH_IPV4_TCP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv4_sctp,
ICE_FDIR_INSET_ETH_IPV4_SCTP, ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6,
ICE_FDIR_INSET_ETH_IPV6,ICE_INSET_NONE, ICE_INSET_NONE},
+ {pattern_eth_ipv6_frag_ext,
ICE_FDIR_INSET_ETH_IPV6,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_udp,
ICE_FDIR_INSET_ETH_IPV6_UDP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_tcp,
ICE_FDIR_INSET_ETH_IPV6_TCP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_sctp,
ICE_FDIR_INSET_ETH_IPV6_SCTP, ICE_INSET_NONE, ICE_INSET_NONE},
@@ -882,11 +885,13 @@ ice_fdir_input_set_parse(uint64_t inset, enum
ice_flow_field *field)
{ICE_INSET_IPV4_TOS, ICE_FLOW_FIELD_IDX_IPV4_DSCP},
{ICE_INSET_IPV4_TTL, ICE_FLOW_FIELD_IDX_IPV4_TTL},
{ICE_INSET_IPV4_PROTO, ICE_FLOW_FIELD_IDX_IPV4_PROT},
+ {ICE_INSET_IPV4_PKID, ICE_FLOW_FIELD_IDX_IPV4_ID},
{ICE_INSET_IPV6_SRC, ICE_FLOW_FIELD_IDX_IPV6_SA},
{ICE_INSET_IPV6_DST, ICE_FLOW_FIELD_IDX_IPV6_DA},
{ICE_INSET_IPV6_TC, ICE_FLOW_FIELD_IDX_IPV6_DSCP},
{ICE_INSET_IPV6_NEXT_HDR, ICE_FLOW_FIELD_IDX_IPV6_PROT},
{ICE_INSET_IPV6_HOP_LIMIT, ICE_FLOW_FIELD_IDX_IPV6_TTL},
+ {ICE_INSET_IPV6_PKID, ICE_FLOW_FIELD_IDX_IPV6_ID},
{ICE_INSET_TCP_SRC_PORT, ICE_FLOW_FIELD_IDX_TCP_SRC_PORT},
{ICE_INSET_TCP_DST_PORT, ICE_FLOW_FIELD_IDX_TCP_DST_PORT},
{ICE_INSET_UDP_SRC_PORT, ICE_FLOW_FIELD_IDX_UDP_SRC_PORT},
@@ -936,6 +941,10 @@ ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow, struct
ice_flow_seg_info *seg)
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV4 |
ICE_FLOW_SEG_HDR_IPV_OTHER);
break;
+ case ICE_FLTR_PTYPE_FRAG_IPV4:
+ ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV4 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG);
+ break;
case ICE_FLTR_PTYPE_NONF_IPV6_UDP:
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_UDP |
ICE_FLOW_SEG_HDR_IPV6 |
@@ -955,6 +964,10 @@ ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow, struct
ice_flow_seg_info *seg)
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV6 |
ICE_FLOW_SEG_HDR_IPV_OTHER);
break;
+ case ICE_FLTR_PTYPE_FRAG_IPV6:
+ ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV6 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG);
+ break;
case ICE_FLTR_PTYPE_NONF_IPV4_UDP_VXLAN:
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_UDP |
ICE_FLOW_SEG_HDR_IPV4 |
@@ -1599,8 +1612,10 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter
*ad,
enum rte_flow_item_type l3 = RTE_FLOW_ITEM_TYPE_END;
enum ice_fdir_tunnel_type tunnel_type =
[dpdk-dev] [PATCH v4 1/3] net/ice/base: support IP fragment RSS and FDIR
Add support for IP fragment RSS hash and FDIR according to packet ID.
Separate IP fragment and IP other packet types.
Signed-off-by: Ting Xu
Signed-off-by: Jeff Guo
---
drivers/net/ice/base/ice_fdir.c | 50 +++--
drivers/net/ice/base/ice_fdir.h | 22 ---
drivers/net/ice/base/ice_flow.c | 50 -
drivers/net/ice/base/ice_flow.h | 5 +++-
drivers/net/ice/base/ice_type.h | 1 +
5 files changed, 120 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ice/base/ice_fdir.c b/drivers/net/ice/base/ice_fdir.c
index 2b39c13127..a9a14b7445 100644
--- a/drivers/net/ice/base/ice_fdir.c
+++ b/drivers/net/ice/base/ice_fdir.c
@@ -518,6 +518,24 @@ static const u8 ice_fdir_ipv4_udp_ecpri_tp0_pkt[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};
+static const u8 ice_fdir_ipv6_frag_pkt[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x86, 0xDD, 0x60, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x2C, 0x40, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3B, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+};
+
+static const u8 ice_fdir_ipv4_frag_pkt[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x45, 0x00,
+ 0x00, 0x14, 0x00, 0x00, 0x20, 0x00, 0x40, 0x10,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00
+};
static const u8 ice_fdir_tcpv6_pkt[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x86, 0xDD, 0x60, 0x00,
@@ -716,6 +734,16 @@ static const struct ice_fdir_base_pkt ice_fdir_pkt[] = {
sizeof(ice_fdir_ipv4_pkt), ice_fdir_ipv4_pkt,
sizeof(ice_fdir_ip4_tun_pkt), ice_fdir_ip4_tun_pkt,
},
+ {
+ ICE_FLTR_PTYPE_FRAG_IPV4,
+ sizeof(ice_fdir_ipv4_frag_pkt), ice_fdir_ipv4_frag_pkt,
+ sizeof(ice_fdir_ipv4_frag_pkt), ice_fdir_ipv4_frag_pkt,
+ },
+ {
+ ICE_FLTR_PTYPE_FRAG_IPV6,
+ sizeof(ice_fdir_ipv6_frag_pkt), ice_fdir_ipv6_frag_pkt,
+ sizeof(ice_fdir_ipv6_frag_pkt), ice_fdir_ipv6_frag_pkt,
+ },
{
ICE_FLTR_PTYPE_NONF_IPV4_GTPU,
sizeof(ice_fdir_ipv4_gtpu4_pkt),
@@ -1505,7 +1533,7 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct
ice_fdir_fltr *input,
ice_pkt_insert_u8(loc, ICE_IPV4_TTL_OFFSET, input->ip.v4.ttl);
ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
if (frag)
- loc[20] = ICE_FDIR_IPV4_PKT_FLAG_DF;
+ loc[20] = ICE_FDIR_IPV4_PKT_FLAG_MF;
break;
case ICE_FLTR_PTYPE_NONF_IPV4_UDP:
ice_pkt_insert_mac_addr(pkt, input->ext_data_outer.dst_mac);
@@ -1808,6 +1836,23 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct
ice_fdir_fltr *input,
input->ip.v6.proto);
ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
break;
+ case ICE_FLTR_PTYPE_FRAG_IPV4:
+ ice_pkt_insert_u32(loc, ICE_IPV4_DST_ADDR_OFFSET,
+ input->ip.v4.src_ip);
+ ice_pkt_insert_u32(loc, ICE_IPV4_SRC_ADDR_OFFSET,
+ input->ip.v4.dst_ip);
+ ice_pkt_insert_u8(loc, ICE_IPV4_TOS_OFFSET, input->ip.v4.tos);
+ ice_pkt_insert_u16(loc, ICE_IPV4_ID_OFFSET,
+ input->ip.v4.packet_id);
+ ice_pkt_insert_u8(loc, ICE_IPV4_TTL_OFFSET, input->ip.v4.ttl);
+ ice_pkt_insert_u8(loc, ICE_IPV4_PROTO_OFFSET,
+ input->ip.v4.proto);
+ ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
+ break;
+ case ICE_FLTR_PTYPE_FRAG_IPV6:
+ ice_pkt_insert_u32(loc, ICE_IPV6_ID_OFFSET,
+ input->ip.v6.packet_id);
+ break;
default:
return ICE_ERR_PARAM;
}
@@ -1838,7 +1883,8 @@ ice_fdir_get_prgm_pkt(struct ice_fdir_fltr *input, u8
*pkt, bool frag)
*/
bool ice_fdir_has_frag(enum ice_fltr_ptype flow)
{
- if (flow == ICE_FLTR_PTYPE_NONF_IPV4_OTHER)
+ if (flow == ICE_FLTR_PTYPE_FRAG_IPV4 ||
+ flow == ICE_FLTR_PTYPE_FRAG_IPV6)
return true;
else
return false;
diff --git a/drivers/net/ice/base/ice_fdir.h b/drivers/net/ice/base/ice_fdir.h
index 6573f96bc1..2acc1d6f1b 100644
--- a/drivers/net/ice/base/ice_fdir.h
+++ b/drivers/net/ice/base/ice_fdir.h
@@ -43,9 +43,11 @@
#define ICE_MAC_ETHTYPE_OFFSET 12
#define ICE_IPV4_TOS_OFFSET15
#define ICE_IPV4_T
Re: [dpdk-dev] [pull-request] dpdk-next-net-eventdev - 21.05 - PRE-RC1
On Tue, Apr 13, 2021 at 12:46 PM David Marchand wrote: > > On Tue, Apr 13, 2021 at 12:12 AM Thomas Monjalon wrote: > > > > 12/04/2021 15:20, Jerin Jacob Kollanukkaran: > > > http://dpdk.org/git/next/dpdk-next-eventdev > > > > Pulled, thanks. > > > > Note few changes in titles like uppercases for acronyms, > > or "add support" simplified as "support", > > and release notes moved in the right place. > > The ABI check now reports an error on event/dlb. > The reason is that the event/dlb driver has been removed, and so the > check complains about a missing dump. > This will have to be fixed quickly or reverted. > > > This has been missed by multiple people, so trying to understand why. I was running the following script[1] to detect ABI issues. Since the "./devtools/test-meson-builds.sh" did not return non zero value or the error print was "Error: cannot find librte_event_dlb.dump", It is missed from my side. @David Marchand @Thomas Monjalon Could you share the snippet you are using for detecting the ABI issue. # ABI check DPDK_ABI_REF_VERSION=v20.11 DPDK_ABI_REF_DIR=/tmp bash ./devtools/test-meson-builds.sh 1> /tmp/build.log 2> /tmp/build.log if [ $? -ne 0 ]; then echo "ABI check failed" exit fi grep "Error: ABI issue reported" /tmp/build.log if [ $? -eq 0 ]; then echo "ABI issue" exit fi --- > > The ABI check should have caught this when run by maintainers (/me > looks at Thomas and Jerin). Sorry for that :-(
Re: [dpdk-dev] [PATCH v2] ethdev: add sanity checks in control APIs
13/04/2021 10:44, Andrew Rybchenko:
> On 4/13/21 6:22 AM, Min Hu (Connor) wrote:
> > @@ -678,6 +684,9 @@ rte_eth_dev_owner_set(const uint16_t port_id,
> > {
> > int ret;
> >
> > + if (owner == NULL)
> > + return -EINVAL;
> > +
>
> Here and in many-many cases below I think the order of checks
> is important in cases when different error codes are returned.
> When there is no any very good reasons why arguments should
> be checked in different order, arguments should be checked in
> order specified in function prototype. In this cases (and many
> cases below), port_id should be checked first.
>
> In this particular case it means that the pointer check
> should be done in a static helper function.
>
> One more point is error logging in the case of failure.
> Right now I'd use RTE_ETHDEV_LOG(ERR, ...). May be later we'll
> find out that some of messages should be made INFO or DEBUG.
> Something like:
>RTE_ETHDEV_LOG(ERR, "Failed to set ethdev port %u owner to NULL\n",
> port_id);
>
> I'm not 100% sure in format, but my requirements are:
> - log messages should be unique
> - log messages should be human readable (i.e. I'd avoid
>usage of function name)
> - log messages should provide enough information to understand
>what went wrong and provide context (basically it correlates
>with uniqueness requirement)
>
> @Thomas, @Ferruh, what do you think? It would be good if we
> reach an argement before mass changes are done?
I agree with all your comments Andrew.
> > @@ -2491,6 +2515,12 @@ rte_eth_tx_done_cleanup(uint16_t port_id, uint16_t
> > queue_id, uint32_t free_cnt)
> > RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_done_cleanup, -ENOTSUP);
> >
> > + if (queue_id >= dev->data->nb_tx_queues) {
> > + RTE_ETHDEV_LOG(ERR, "Queue id should be < %u.",
> > + dev->data->nb_tx_queues);
> > + return -EINVAL;
> > + }
> > +
>
> I'm not 100% sure that it is a control path.
Indeed it can be used in the data path of some algorithms.
Re: [dpdk-dev] [pull-request] dpdk-next-net-eventdev - 21.05 - PRE-RC1
13/04/2021 10:54, Jerin Jacob: > On Tue, Apr 13, 2021 at 12:46 PM David Marchand > wrote: > > > > On Tue, Apr 13, 2021 at 12:12 AM Thomas Monjalon > > wrote: > > > > > > 12/04/2021 15:20, Jerin Jacob Kollanukkaran: > > > > http://dpdk.org/git/next/dpdk-next-eventdev > > > > > > Pulled, thanks. > > > > > > Note few changes in titles like uppercases for acronyms, > > > or "add support" simplified as "support", > > > and release notes moved in the right place. > > > > The ABI check now reports an error on event/dlb. > > The reason is that the event/dlb driver has been removed, and so the > > check complains about a missing dump. > > This will have to be fixed quickly or reverted. > > > > > > This has been missed by multiple people, so trying to understand why. > > > I was running the following script[1] to detect ABI issues. > Since the "./devtools/test-meson-builds.sh" did not return non zero value or > the error print was "Error: cannot find librte_event_dlb.dump", It is > missed from my side. > > @David Marchand @Thomas Monjalon Could you share the snippet you are > using for detecting the ABI issue. I do like you: simply run test-meson-builds.sh And yes I saw the error, and I don't know why I thought it was OK! We are humans :) > > # ABI check > DPDK_ABI_REF_VERSION=v20.11 DPDK_ABI_REF_DIR=/tmp bash > ./devtools/test-meson-builds.sh 1> /tmp/build.log 2> /tmp/build.log > if [ $? -ne 0 ]; then > echo "ABI check failed" > exit > fi > > grep "Error: ABI issue reported" /tmp/build.log > if [ $? -eq 0 ]; then > echo "ABI issue" > exit > fi > > --- > > > > The ABI check should have caught this when run by maintainers (/me > > looks at Thomas and Jerin). > > Sorry for that :-(
Re: [dpdk-dev] [PATCH v4 0/3] support flow for IP fragment in ICE
Best Regards, Xu Ting > -Original Message- > From: Guo, Jia > Sent: Tuesday, April 13, 2021 4:48 PM > To: Zhang, Qi Z ; Yang, Qiming > > Cc: dev@dpdk.org; Xu, Ting ; Guo, Jia > Subject: [PATCH v4 0/3] support flow for IP fragment in ICE > > Support RSS hash and FDIR for IP fragment packets in ICE PMD. > > v4: > correct typo when define fragment > v3: > rebase code and fix some parsing issues. > v2: > add some input check > > Jeff Guo (3): > net/ice/base: support IP fragment RSS and FDIR > net/ice: support RSS hash for IP fragment > net/ice: support FDIR for IP fragment packet > > drivers/net/ice/base/ice_fdir.c| 50 - > drivers/net/ice/base/ice_fdir.h| 22 +- > drivers/net/ice/base/ice_flow.c| 50 - > drivers/net/ice/base/ice_flow.h| 5 +- > drivers/net/ice/base/ice_type.h| 1 + > drivers/net/ice/ice_fdir_filter.c | 116 ++--- > drivers/net/ice/ice_generic_flow.c | 22 ++ > drivers/net/ice/ice_generic_flow.h | 6 ++ > drivers/net/ice/ice_hash.c | 48 ++-- > 9 files changed, 293 insertions(+), 27 deletions(-) > > -- > 2.20.1 Reviewed-by: Ting Xu
Re: [dpdk-dev] [PATCH] net/hns3: support trace Rx/Tx burst function
On Tue, Apr 13, 2021 at 10:37 AM Ferruh Yigit wrote: > > On 4/9/2021 11:26 AM, Min Hu (Connor) wrote: > > From: Chengwen Feng > > > > This patch adds debug info for Rx/Tx burst function which was choosing. > > > > Signed-off-by: Chengwen Feng > > Signed-off-by: Min Hu (Connor) > > Applied to dpdk-next-net/main, thanks. Can we avoid mentioning "trace" in the title? This is to avoid confusion with rte_trace. -- David Marchand
Re: [dpdk-dev] [PATCH v5 1/4] vhost: abstract and reorganize async split ring code
Hi Maxime,
> -Original Message-
> From: Maxime Coquelin
> Sent: Tuesday, April 13, 2021 3:12 PM
> To: Jiang, Cheng1 ; Xia, Chenbo
>
> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> ; Wang, Yinan ; Liu,
> Yong
> Subject: Re: [PATCH v5 1/4] vhost: abstract and reorganize async split ring
> code
>
> Hi Cheng,
>
> On 4/12/21 1:34 PM, Cheng Jiang wrote:
> > In order to improve code efficiency and readability when async packed
> > ring support is enabled. This patch abstract some functions like
> > shadow_ring_store and write_back_completed_descs_split. And improve
> > the efficiency of some pointer offset calculation.
> >
> > Signed-off-by: Cheng Jiang
> > ---
> > lib/librte_vhost/virtio_net.c | 146
> > +++---
> > 1 file changed, 84 insertions(+), 62 deletions(-)
> >
> > diff --git a/lib/librte_vhost/virtio_net.c
> > b/lib/librte_vhost/virtio_net.c index ff3987860..c43ab0093 100644
> > --- a/lib/librte_vhost/virtio_net.c
> > +++ b/lib/librte_vhost/virtio_net.c
> > @@ -1458,6 +1458,29 @@ virtio_dev_rx_async_get_info_idx(uint16_t
> pkts_idx,
> > (vq_size - n_inflight + pkts_idx) & (vq_size - 1); }
> >
> > +static __rte_always_inline void
> > +shadow_ring_store(struct vhost_virtqueue *vq, void *shadow_ring, void
> *d_ring,
> > + uint16_t s_idx, uint16_t d_idx,
> > + uint16_t count, uint16_t elem_size) {
> > + if (d_idx + count <= vq->size) {
> > + rte_memcpy((void *)((uintptr_t)d_ring + d_idx * elem_size),
> > + (void *)((uintptr_t)shadow_ring + s_idx * elem_size),
> > + count * elem_size);
> > + } else {
> > + uint16_t size = vq->size - d_idx;
> > +
> > + rte_memcpy((void *)((uintptr_t)d_ring + d_idx * elem_size),
> > + (void *)((uintptr_t)shadow_ring + s_idx * elem_size),
> > + size * elem_size);
> > +
> > + rte_memcpy((void *)((uintptr_t)d_ring),
> > + (void *)((uintptr_t)shadow_ring +
> > + (s_idx + size) * elem_size),
> > + (count - size) * elem_size);
> > + }
> > +}
> > +
> > static __rte_noinline uint32_t
> > virtio_dev_rx_async_submit_split(struct virtio_net *dev,
> > struct vhost_virtqueue *vq, uint16_t queue_id, @@ -1478,6 +1501,7
> @@
> > virtio_dev_rx_async_submit_split(struct virtio_net *dev,
> > struct rte_vhost_iov_iter *dst_it = it_pool + 1;
> > uint16_t slot_idx = 0;
> > uint16_t segs_await = 0;
> > + uint16_t iovec_idx = 0, it_idx = 0;
> > struct async_inflight_info *pkts_info = vq->async_pkts_info;
> > uint32_t n_pkts = 0, pkt_err = 0;
> > uint32_t num_async_pkts = 0, num_done_pkts = 0; @@ -1513,27
> +1537,32
> > @@ virtio_dev_rx_async_submit_split(struct virtio_net *dev,
> >
> > if (async_mbuf_to_desc(dev, vq, pkts[pkt_idx],
> > buf_vec, nr_vec, num_buffers,
> > - src_iovec, dst_iovec, src_it, dst_it) < 0) {
> > + &src_iovec[iovec_idx],
> > + &dst_iovec[iovec_idx],
> > + &src_it[it_idx],
> > + &dst_it[it_idx]) < 0) {
> > vq->shadow_used_idx -= num_buffers;
> > break;
> > }
> >
> > slot_idx = (vq->async_pkts_idx + num_async_pkts) &
> > (vq->size - 1);
> > - if (src_it->count) {
> > + if (src_it[it_idx].count) {
> > uint16_t from, to;
> >
> > - async_fill_desc(&tdes[pkt_burst_idx++], src_it,
> dst_it);
> > + async_fill_desc(&tdes[pkt_burst_idx++],
> > + &src_it[it_idx],
> > + &dst_it[it_idx]);
> > pkts_info[slot_idx].descs = num_buffers;
> > pkts_info[slot_idx].mbuf = pkts[pkt_idx];
> > async_pkts_log[num_async_pkts].pkt_idx = pkt_idx;
> > async_pkts_log[num_async_pkts++].last_avail_idx =
> > vq->last_avail_idx;
> > - src_iovec += src_it->nr_segs;
> > - dst_iovec += dst_it->nr_segs;
> > - src_it += 2;
> > - dst_it += 2;
> > - segs_await += src_it->nr_segs;
> > +
> > + iovec_idx += src_it[it_idx].nr_segs;
> > + it_idx += 2;
> > +
> > + segs_await += src_it[it_idx].nr_segs;
> >
> > /**
> > * recover shadow used ring and keep DMA-occupied
> @@ -1541,23
> > +1570,12 @@ virtio_dev_rx_async_submit_split(struct virtio_net *dev,
> > */
> > from = vq->shadow_used_idx - num_buffers;
> > to = vq->async_desc_idx & (vq->size - 1);
> > - if (num_buffers + to <= vq->size) {
> > -
Re: [dpdk-dev] [pull-request] dpdk-next-net-eventdev - 21.05 - PRE-RC1
On Tue, Apr 13, 2021 at 10:55 AM Jerin Jacob wrote: > I was running the following script[1] to detect ABI issues. > Since the "./devtools/test-meson-builds.sh" did not return non zero value or > the error print was "Error: cannot find librte_event_dlb.dump", It is > missed from my side. > > @David Marchand @Thomas Monjalon Could you share the snippet you are > using for detecting the ABI issue. > > > > # ABI check > DPDK_ABI_REF_VERSION=v20.11 DPDK_ABI_REF_DIR=/tmp bash Ah ok, this is because event/dlb did not exist in 20.11. Running against 21.02, you should get the error. -- David Marchand
Re: [dpdk-dev] [pull-request] dpdk-next-net-eventdev - 21.05 - PRE-RC1
13/04/2021 11:07, David Marchand: > On Tue, Apr 13, 2021 at 10:55 AM Jerin Jacob wrote: > > I was running the following script[1] to detect ABI issues. > > Since the "./devtools/test-meson-builds.sh" did not return non zero value or > > the error print was "Error: cannot find librte_event_dlb.dump", It is > > missed from my side. > > > > @David Marchand @Thomas Monjalon Could you share the snippet you are > > using for detecting the ABI issue. > > > > > > > > # ABI check > > DPDK_ABI_REF_VERSION=v20.11 DPDK_ABI_REF_DIR=/tmp bash > > Ah ok, this is because event/dlb did not exist in 20.11. No it was added in 20.11. > Running against 21.02, you should get the error. Yes we should always run the ABI check against the latest release. It means you must upgrade DPDK_ABI_REF_VERSION after each release.
Re: [dpdk-dev] [PATCH] net/hns3: support trace Rx/Tx burst function
On 4/13/2021 10:03 AM, David Marchand wrote: On Tue, Apr 13, 2021 at 10:37 AM Ferruh Yigit wrote: On 4/9/2021 11:26 AM, Min Hu (Connor) wrote: From: Chengwen Feng This patch adds debug info for Rx/Tx burst function which was choosing. Signed-off-by: Chengwen Feng Signed-off-by: Min Hu (Connor) Applied to dpdk-next-net/main, thanks. Can we avoid mentioning "trace" in the title? This is to avoid confusion with rte_trace. Indeed, I also though if it is adding rte_trace support when I first see the title, I will update it to: "net/hns3: log selected datapath"
Re: [dpdk-dev] [pull-request] dpdk-next-net-eventdev - 21.05 - PRE-RC1
On Tue, Apr 13, 2021 at 11:07 AM David Marchand wrote: > > On Tue, Apr 13, 2021 at 10:55 AM Jerin Jacob wrote: > > I was running the following script[1] to detect ABI issues. > > Since the "./devtools/test-meson-builds.sh" did not return non zero value or > > the error print was "Error: cannot find librte_event_dlb.dump", It is > > missed from my side. > > > > @David Marchand @Thomas Monjalon Could you share the snippet you are > > using for detecting the ABI issue. > > > > > > > > # ABI check > > DPDK_ABI_REF_VERSION=v20.11 DPDK_ABI_REF_DIR=/tmp bash > > Ah ok, this is because event/dlb did not exist in 20.11. > Running against 21.02, you should get the error. Clicked send too quickly... No, it did exist. $ DPDK_ABI_REF_VERSION=v20.11 ./devtools/test-meson-builds.sh ninja: Entering directory `/home/dmarchan/builds/build-gcc-static' ninja: no work to do. ninja: Entering directory `/home/dmarchan/builds/build-gcc-shared' ninja: no work to do. Error: cannot find librte_event_dlb.dump in /home/dmarchan/builds/build-gcc-shared/install Hum... the next reason I see would be that your reference does not have event/dlb which is surprising with default configuration. $ ls $DPDK_ABI_REF_DIR/*/*/dump/*dlb.dump /home/dmarchan/abi/v20.11/build-clang-shared/dump/librte_event_dlb.dump /home/dmarchan/abi/v21.02/build-clang-shared/dump/librte_event_dlb.dump /home/dmarchan/abi/v20.11/build-gcc-shared/dump/librte_event_dlb.dump /home/dmarchan/abi/v21.02/build-gcc-shared/dump/librte_event_dlb.dump -- David Marchand
Re: [dpdk-dev] [PATCH] devtools: skip removed DLB driver in ABI check
On Tue, Apr 13, 2021 at 10:45 AM Thomas Monjalon wrote:
>
> The eventdev driver DLB was removed in DPDK 21.05,
> breaking the ABI check.
> The exception was agreed so we just need to skip this check.
>
> Note: complete removal of a driver cannot be ignored
> in devtools/libabigail.abignore, so the script must be patched.
Indeed, abidiff wants to compare two shared libraries/dumps.
In this situation, we don't have a second library/dump.
>
> Fixes: 698fa829415d ("event/dlb: remove driver")
>
> Reported-by: David Marchand
> Signed-off-by: Thomas Monjalon
Reviewed-by: David Marchand
--
David Marchand
Re: [dpdk-dev] [PATCH v2] ethdev: add sanity checks in control APIs
On 4/13/2021 9:58 AM, Thomas Monjalon wrote:
13/04/2021 10:44, Andrew Rybchenko:
On 4/13/21 6:22 AM, Min Hu (Connor) wrote:
@@ -678,6 +684,9 @@ rte_eth_dev_owner_set(const uint16_t port_id,
{
int ret;
+ if (owner == NULL)
+ return -EINVAL;
+
Here and in many-many cases below I think the order of checks
is important in cases when different error codes are returned.
When there is no any very good reasons why arguments should
be checked in different order, arguments should be checked in
order specified in function prototype. In this cases (and many
cases below), port_id should be checked first.
In this particular case it means that the pointer check
should be done in a static helper function.
One more point is error logging in the case of failure.
Right now I'd use RTE_ETHDEV_LOG(ERR, ...). May be later we'll
find out that some of messages should be made INFO or DEBUG.
Something like:
RTE_ETHDEV_LOG(ERR, "Failed to set ethdev port %u owner to NULL\n",
port_id);
I'm not 100% sure in format, but my requirements are:
- log messages should be unique
- log messages should be human readable (i.e. I'd avoid
usage of function name)
- log messages should provide enough information to understand
what went wrong and provide context (basically it correlates
with uniqueness requirement)
@Thomas, @Ferruh, what do you think? It would be good if we
reach an argement before mass changes are done?
I agree with all your comments Andrew.
+1
@@ -2491,6 +2515,12 @@ rte_eth_tx_done_cleanup(uint16_t port_id, uint16_t
queue_id, uint32_t free_cnt)
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_done_cleanup, -ENOTSUP);
+ if (queue_id >= dev->data->nb_tx_queues) {
+ RTE_ETHDEV_LOG(ERR, "Queue id should be < %u.",
+ dev->data->nb_tx_queues);
+ return -EINVAL;
+ }
+
I'm not 100% sure that it is a control path.
Indeed it can be used in the data path of some algorithms.
Re: [dpdk-dev] [PATCH v4 2/2] ethdev: update qfi definition
Hi Raslan,
> -Original Message-
> From: Raslan Darawsheh
> Subject: RE: [PATCH v4 2/2] ethdev: update qfi definition
>
> Hi,
>
> > -Original Message-
> > From: Ferruh Yigit
> > Sent: Tuesday, April 6, 2021 7:10 PM
> > To: Raslan Darawsheh ; dev@dpdk.org; Ori Kam
> > ; andrew.rybche...@oktetlabs.ru
> > Cc: ivan.ma...@oktetlabs.ru; ying.a.w...@intel.com;
> > olivier.m...@6wind.com; Slava Ovsiienko ; Shiri
> > Kuzin ; sta...@dpdk.org; David Marchand
> > ; NBU-Contact-Thomas Monjalon
> >
> > Subject: Re: [PATCH v4 2/2] ethdev: update qfi definition
> >
> > On 4/4/2021 8:45 AM, Raslan Darawsheh wrote:
> > > qfi field is 8 bits which represent single bit for
> > > PPP (paging Policy Presence) single bit for RQI
> > > (Reflective QoS Indicator) and 6 bits for qfi
> > > (QoS Flow Identifier) based on RFC 38415-g30
> > >
> > > This update the doxygen format and the mask for qfi
> > > to properly identify the full 8 bits of the field.
> > >
> > > note: changing the default mask would cause different
> > > patterns generated by testpmd.
> > >
> > > Fixes: 346553db5bd1 ("ethdev: add GTP extension header to flow API")
> > > Cc: ying.a.w...@intel.com
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Raslan Darawsheh
> > > ---
> > > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 ++-
> > > lib/librte_ethdev/rte_flow.h| 20 +---
> > > 2 files changed, 19 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > > index f59eb8a27d..dd39c4c3c2 100644
> > > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > > @@ -3742,7 +3742,8 @@ This section lists supported pattern items and
> > their attributes, if any.
> > > - ``gtp_psc``: match GTP PDU extension header with type 0x85.
> > >
> > > - ``pdu_type {unsigned}``: PDU type.
> > > - - ``qfi {unsigned}``: QoS flow identifier.
> > > +
> > > + - ``qfi {unsigned}``: PPP, RQI and QoS flow identifier.
> > >
> > > - ``pppoes``, ``pppoed``: match PPPoE header.
> > >
> > > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > > index 6cc57136ac..20b4389429 100644
> > > --- a/lib/librte_ethdev/rte_flow.h
> > > +++ b/lib/librte_ethdev/rte_flow.h
> > > @@ -20,6 +20,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -1421,16 +1422,29 @@ static const struct rte_flow_item_meta
> > rte_flow_item_meta_mask = {
> > >*
> > >* Matches a GTP PDU extension header with type 0x85.
> > >*/
> > > +RTE_STD_C11
> > > struct rte_flow_item_gtp_psc {
> > > - uint8_t pdu_type; /**< PDU type. */
> > > - uint8_t qfi; /**< QoS flow identifier. */
> > > + union {
> > > + struct {
> > > + /*
> > > + * These fields are retained for compatibility.
> > > + * Please switch to the new header field below.
> > > + */
> > > + uint8_t pdu_type; /**< PDU type. */
> > > + uint8_t qfi; /**< PPP, RQI, QoS flow identifier. */
> > > +
> > > + };
> > > + struct rte_gtp_psc_hdr hdr;
> > > + };
> > > };
> >
> > This will change the struct size even with union, since old version is
> > missing
> > all fields from protocol header. Struct size will go from 2 --> 5 bytes [1].
> >
> > Since this is public struct, we can't change its size.
> >
> > @Ori, Andrew,
> >
> > Do you have a suggestion for next step?
> >
I think Ferruh is right, and I think that we should at this point just update
the documentation.
Sorry for the detour
Just small comment about the original patch.
I don’t think you should change the default mask since it may break existing
apps.
> > - We can still add the "struct rte_gtp_psc_hdr", and add a deprecation
> > notice
> > for "struct rte_flow_item_gtp_psc" to say it will use "struct
> > rte_gtp_psc_hdr"
> > on 21.11.
> >
> > - And for this release use the Raslan's first version:
> >-uint8_t qfi; /**< QoS flow identifier. */
> >+uint8_t qfi; /**< PPP, RQI, QoS flow identifier. */
> >
> >
> > Does it make sense? Any comments?
> >
> @Ori Kam, @andrew.rybche...@oktetlabs.ru,
> This is a kind remainder of this patch,
>
> >
> >
> > [1]
> > struct rte_gtp_psc_hdr {
> > uint8_text_hdr_len; /* 0 1 */
> > uint8_ttype:4; /* 1: 0 1 */
> > uint8_tqmp:1;/* 1: 4 1 */
> >
> > /* XXX 3 bits hole, try to pack */
> >
> > union {
> > struct {
> > uint8_tsnp:1;/* 2: 0 1 */
> > uint8_tspare_dl1:2; /* 2: 1 1 */
> > };
Re: [dpdk-dev] [PATCH v2 0/7] Bugfix for hns3 PMD
On 4/10/2021 2:11 AM, Min Hu (Connor) wrote: This set of patches contains seven bugfixes for hns3 PMD. Chengchang Tang (3): net/hns3: fix incorrect timing in resetting queues net/hns3: fix queue state when concurrent with reset net/hns3: fix configure FEC when concurrent with reset Chengwen Feng (2): net/hns3: remove variables of selecting Rx/Tx function net/hns3: fix some packet type calc error Hongbo Zheng (1): net/hns3: fix FLR failure when RAS concurrent with FLR Min Hu (Connor) (1): net/hns3: fix missing rollback in PF init Series applied to dpdk-next-net/main, thanks.
Re: [dpdk-dev] [PATCH v4 0/4] support flow for IP fragment in IAVF
> -Original Message- > From: Guo, Jia > Sent: Tuesday, April 13, 2021 4:10 PM > To: or...@nvidia.com; Zhang, Qi Z ; Xing, Beilei > ; Li, Xiaoyun ; Wu, Jingjing > > Cc: dev@dpdk.org; Xu, Ting ; Guo, Jia > Subject: [PATCH v4 0/4] support flow for IP fragment in IAVF > > support flow for IP fragment in IAVF > > v4: > add some part which should not be deleted > v3: > rebase code and fix some parsing issues > v2: > refine some input check > > Jeff Guo (4): > app/testpmd: add packet id for IP fragment > common/iavf: add proto header for IP fragment > net/iavf: support RSS hash for IP fragment > net/iavf: support FDIR for IP fragment packet > > app/test-pmd/cmdline_flow.c | 21 +- > drivers/common/iavf/virtchnl.h | 7 + > drivers/net/iavf/iavf_fdir.c | 386 ++- > drivers/net/iavf/iavf_generic_flow.c | 24 ++ > drivers/net/iavf/iavf_generic_flow.h | 8 + > drivers/net/iavf/iavf_hash.c | 83 +- > 6 files changed, 394 insertions(+), 135 deletions(-) > > -- > 2.20.1 For Patch 2,3,4 Acked-by: Qi Zhang Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [PATCH] devtools: skip removed DLB driver in ABI check
13/04/2021 11:15, David Marchand:
> On Tue, Apr 13, 2021 at 10:45 AM Thomas Monjalon wrote:
> >
> > The eventdev driver DLB was removed in DPDK 21.05,
> > breaking the ABI check.
> > The exception was agreed so we just need to skip this check.
> >
> > Note: complete removal of a driver cannot be ignored
> > in devtools/libabigail.abignore, so the script must be patched.
>
> Indeed, abidiff wants to compare two shared libraries/dumps.
> In this situation, we don't have a second library/dump.
>
> > Fixes: 698fa829415d ("event/dlb: remove driver")
> >
> > Reported-by: David Marchand
> > Signed-off-by: Thomas Monjalon
> Reviewed-by: David Marchand
Applied
Re: [dpdk-dev] [PATCH 3/4] vhost: avoid deadlock on async register
On 3/30/21 3:20 AM, Hu, Jiayu wrote:
> Hi Maxime,
>
>> -Original Message-
>> From: Maxime Coquelin
>> Sent: Monday, March 29, 2021 11:19 PM
>> To: Hu, Jiayu ; dev@dpdk.org
>> Cc: Xia, Chenbo ; Wang, Yinan
>> ; Jiang, Cheng1 ; Pai G,
>> Sunil
>> Subject: Re: [PATCH 3/4] vhost: avoid deadlock on async register
>>
>>
>>
>> On 3/17/21 1:56 PM, Jiayu Hu wrote:
>>> Users register async copy device when vhost queue is enabled.
>>> However, if VHOST_USER_F_PROTOCOL_FEATURES is not supported,
>>> a deadlock occurs inside rte_vhost_async_channel_register(),
>>> as vhost_user_msg_handler() already takes vq->access_lock
>>> before processing VHOST_USER_SET_VRING_KICK message.
>>>
>>> This patch removes calling vring_state_changed() in
>>> vhost_user_set_vring_kick() to avoid deadlock on async register.
>>>
>>> Signed-off-by: Jiayu Hu
>>> ---
>>> lib/librte_vhost/vhost_user.c | 3 ---
>>> 1 file changed, 3 deletions(-)
>>>
>>> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
>>> index 399675c..a319c1c 100644
>>> --- a/lib/librte_vhost/vhost_user.c
>>> +++ b/lib/librte_vhost/vhost_user.c
>>> @@ -1919,9 +1919,6 @@ vhost_user_set_vring_kick(struct virtio_net
>> **pdev, struct VhostUserMsg *msg,
>>> */
>>> if (!(dev->features & (1ULL <<
>> VHOST_USER_F_PROTOCOL_FEATURES))) {
>>> vq->enabled = 1;
>>> - if (dev->notify_ops->vring_state_changed)
>>> - dev->notify_ops->vring_state_changed(
>>> - dev->vid, file.index, 1);
>>
>> That looks very wrong, as:
>> 1. The apps want to receive this notification. It looks like breaking
>> existing apps in order to support the experimental async datapath. E.g.
>> OVS needs it to start polling the queues when protocol features is not
>> negotiated.
>
> IMHO, if protocol feature is not negotiated, vring_state_chaned will also
> be called in vhost_user_msg_handler. In the case you mentioned,
> vq->enabled is set to true in set_vring_kick, and in vhost_user_msg_handler,
> "cur_ready != (vq && vq->ready)" is true, as vq->ready is false when init. So
> vhost_user_msg_handler will call vhost_user_notify_queue_state, which
> calls set_vring_kick inside.
OK, I agree, we can drop this one.
But it is not enough as vhost_user_notify_queue_state() is called at
several place with the lock taken.
> In addition, calling vring_state_changed in set_vring_kick is protected by
> lock,
> but it's not in in vhost_user_msg_handler. It looks confusing to me. Is there
> any special reason for this design?
I think we need the lock help every time the callback is called, to
avoid the case an application calls a Vhost API that would modify the vq
struct. We could get undefined behavior if it happened.
>
>>
>> 2. The fix in your case seems to indicate that your app's
>> vring_state_changed callback called rte_vhost_async_channel_register.
>> And your fix consists in no more calling the callback, and so no more
>> calling rte_vhost_async_channel_register?
>
> rte_vhost_async_channel_register is recommended to call in
> vring_state_changed, and vring_state_changed will be called
> by vhost_user_msg_handler.
You might want to schedule a thread to call channel registration. Maybe
using rte_set_alarm?
Regards,
Maxime
>
> Thanks,
> Jiayu
>>
>>> }
>>>
>>> if (vq->ready) {
>>>
>
[dpdk-dev] [PATCH v5 2/3] net/ice: support RSS hash for IP fragment
New pattern and RSS hash flow parsing are added to handle fragmented
IPv4/IPv6 packet.
Signed-off-by: Jeff Guo
---
drivers/net/ice/ice_generic_flow.c | 21 ++
drivers/net/ice/ice_generic_flow.h | 6
drivers/net/ice/ice_hash.c | 46 --
3 files changed, 65 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ice/ice_generic_flow.c
b/drivers/net/ice/ice_generic_flow.c
index 8704812622..2389bc6637 100644
--- a/drivers/net/ice/ice_generic_flow.c
+++ b/drivers/net/ice/ice_generic_flow.c
@@ -212,6 +212,27 @@ enum rte_flow_item_type pattern_eth_qinq_ipv6[] = {
RTE_FLOW_ITEM_TYPE_IPV6,
RTE_FLOW_ITEM_TYPE_END,
};
+enum rte_flow_item_type pattern_eth_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+enum rte_flow_item_type pattern_eth_vlan_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+enum rte_flow_item_type pattern_eth_qinq_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
enum rte_flow_item_type pattern_eth_ipv6_udp[] = {
RTE_FLOW_ITEM_TYPE_ETH,
RTE_FLOW_ITEM_TYPE_IPV6,
diff --git a/drivers/net/ice/ice_generic_flow.h
b/drivers/net/ice/ice_generic_flow.h
index 9f422e5925..2afe719264 100644
--- a/drivers/net/ice/ice_generic_flow.h
+++ b/drivers/net/ice/ice_generic_flow.h
@@ -52,6 +52,7 @@
#define ICE_L2TPV3OIP_SESSION_ID BIT_ULL(43)
#define ICE_PFCP_SEID BIT_ULL(42)
#define ICE_PFCP_S_FIELD BIT_ULL(41)
+#define ICE_IP_PK_ID BIT_ULL(40)
/* input set */
@@ -69,11 +70,13 @@
#define ICE_INSET_IPV4_TOS (ICE_PROT_IPV4 | ICE_IP_TOS)
#define ICE_INSET_IPV4_PROTO (ICE_PROT_IPV4 | ICE_IP_PROTO)
#define ICE_INSET_IPV4_TTL (ICE_PROT_IPV4 | ICE_IP_TTL)
+#define ICE_INSET_IPV4_PKID(ICE_PROT_IPV4 | ICE_IP_PK_ID)
#define ICE_INSET_IPV6_SRC (ICE_PROT_IPV6 | ICE_IP_SRC)
#define ICE_INSET_IPV6_DST (ICE_PROT_IPV6 | ICE_IP_DST)
#define ICE_INSET_IPV6_NEXT_HDR(ICE_PROT_IPV6 | ICE_IP_PROTO)
#define ICE_INSET_IPV6_HOP_LIMIT (ICE_PROT_IPV6 | ICE_IP_TTL)
#define ICE_INSET_IPV6_TC (ICE_PROT_IPV6 | ICE_IP_TOS)
+#define ICE_INSET_IPV6_PKID(ICE_PROT_IPV6 | ICE_IP_PK_ID)
#define ICE_INSET_TCP_SRC_PORT (ICE_PROT_TCP | ICE_SPORT)
#define ICE_INSET_TCP_DST_PORT (ICE_PROT_TCP | ICE_DPORT)
@@ -202,6 +205,9 @@ extern enum rte_flow_item_type pattern_eth_qinq_ipv4_icmp[];
extern enum rte_flow_item_type pattern_eth_ipv6[];
extern enum rte_flow_item_type pattern_eth_vlan_ipv6[];
extern enum rte_flow_item_type pattern_eth_qinq_ipv6[];
+extern enum rte_flow_item_type pattern_eth_ipv6_frag_ext[];
+extern enum rte_flow_item_type pattern_eth_vlan_ipv6_frag_ext[];
+extern enum rte_flow_item_type pattern_eth_qinq_ipv6_frag_ext[];
extern enum rte_flow_item_type pattern_eth_ipv6_udp[];
extern enum rte_flow_item_type pattern_eth_vlan_ipv6_udp[];
extern enum rte_flow_item_type pattern_eth_qinq_ipv6_udp[];
diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
index e56cdf9941..75b6947625 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -47,8 +47,10 @@
ETH_RSS_NONFRAG_IPV6_TCP | \
ETH_RSS_NONFRAG_IPV6_SCTP)
-#define VALID_RSS_IPV4 (ETH_RSS_IPV4 | VALID_RSS_IPV4_L4)
-#define VALID_RSS_IPV6 (ETH_RSS_IPV6 | VALID_RSS_IPV6_L4)
+#define VALID_RSS_IPV4 (ETH_RSS_IPV4 | ETH_RSS_FRAG_IPV4 | \
+VALID_RSS_IPV4_L4)
+#define VALID_RSS_IPV6 (ETH_RSS_IPV6 | ETH_RSS_FRAG_IPV6 | \
+VALID_RSS_IPV6_L4)
#define VALID_RSS_L3 (VALID_RSS_IPV4 | VALID_RSS_IPV6)
#define VALID_RSS_L4 (VALID_RSS_IPV4_L4 | VALID_RSS_IPV6_L4)
@@ -108,6 +110,7 @@ ice_hash_parse_pattern_action(struct ice_adapter *ad,
/* Rss configuration template */
struct ice_rss_hash_cfg ipv4_tmplt = {
ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG |
ICE_FLOW_SEG_HDR_IPV_OTHER,
ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV4,
ICE_RSS_OUTER_HEADERS,
@@ -146,6 +149,15 @@ struct ice_rss_hash_cfg ipv6_tmplt = {
0
};
+struct ice_rss_hash_cfg ipv6_frag_tmplt = {
+ ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV6 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG |
+ ICE_FLOW_SEG_HDR_IPV_OTHER,
+ ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV6,
+ ICE_RSS_ANY_HEADERS,
+ 0
+};
+
struct ice_rss_hash_cf
[dpdk-dev] [PATCH v5 0/3] support flow for IP fragment in ICE
Support RSS hash and FDIR for IP fragment packets in ICE PMD. v5: rebase code. v4: correct typo when define fragment v3: rebase code and fix some parsing issues. v2: add some input check Jeff Guo (3): net/ice/base: support IP fragment RSS and FDIR net/ice: support RSS hash for IP fragment net/ice: support FDIR for IP fragment packet drivers/net/ice/base/ice_fdir.c| 50 - drivers/net/ice/base/ice_fdir.h| 22 +- drivers/net/ice/base/ice_flow.c| 50 - drivers/net/ice/base/ice_flow.h| 9 ++- drivers/net/ice/base/ice_type.h| 1 + drivers/net/ice/ice_fdir_filter.c | 116 ++--- drivers/net/ice/ice_generic_flow.c | 22 ++ drivers/net/ice/ice_generic_flow.h | 6 ++ drivers/net/ice/ice_hash.c | 46 ++-- 9 files changed, 293 insertions(+), 29 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH v5 1/3] net/ice/base: support IP fragment RSS and FDIR
Add support for IP fragment RSS hash and FDIR according to packet ID.
Separate IP fragment and IP other packet types.
Signed-off-by: Ting Xu
Signed-off-by: Jeff Guo
---
drivers/net/ice/base/ice_fdir.c | 50 +++--
drivers/net/ice/base/ice_fdir.h | 22 ---
drivers/net/ice/base/ice_flow.c | 50 -
drivers/net/ice/base/ice_flow.h | 9 --
drivers/net/ice/base/ice_type.h | 1 +
5 files changed, 122 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ice/base/ice_fdir.c b/drivers/net/ice/base/ice_fdir.c
index 8f9c0d346b..c1b14783ac 100644
--- a/drivers/net/ice/base/ice_fdir.c
+++ b/drivers/net/ice/base/ice_fdir.c
@@ -518,6 +518,24 @@ static const u8 ice_fdir_ipv4_udp_ecpri_tp0_pkt[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};
+static const u8 ice_fdir_ipv6_frag_pkt[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x86, 0xDD, 0x60, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x2C, 0x40, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3B, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+};
+
+static const u8 ice_fdir_ipv4_frag_pkt[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x45, 0x00,
+ 0x00, 0x14, 0x00, 0x00, 0x20, 0x00, 0x40, 0x10,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00
+};
static const u8 ice_fdir_tcpv6_pkt[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x86, 0xDD, 0x60, 0x00,
@@ -716,6 +734,16 @@ static const struct ice_fdir_base_pkt ice_fdir_pkt[] = {
sizeof(ice_fdir_ipv4_pkt), ice_fdir_ipv4_pkt,
sizeof(ice_fdir_ip4_tun_pkt), ice_fdir_ip4_tun_pkt,
},
+ {
+ ICE_FLTR_PTYPE_FRAG_IPV4,
+ sizeof(ice_fdir_ipv4_frag_pkt), ice_fdir_ipv4_frag_pkt,
+ sizeof(ice_fdir_ipv4_frag_pkt), ice_fdir_ipv4_frag_pkt,
+ },
+ {
+ ICE_FLTR_PTYPE_FRAG_IPV6,
+ sizeof(ice_fdir_ipv6_frag_pkt), ice_fdir_ipv6_frag_pkt,
+ sizeof(ice_fdir_ipv6_frag_pkt), ice_fdir_ipv6_frag_pkt,
+ },
{
ICE_FLTR_PTYPE_NONF_IPV4_GTPU,
sizeof(ice_fdir_ipv4_gtpu4_pkt),
@@ -1505,7 +1533,7 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct
ice_fdir_fltr *input,
ice_pkt_insert_u8(loc, ICE_IPV4_TTL_OFFSET, input->ip.v4.ttl);
ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
if (frag)
- loc[20] = ICE_FDIR_IPV4_PKT_FLAG_DF;
+ loc[20] = ICE_FDIR_IPV4_PKT_FLAG_MF;
break;
case ICE_FLTR_PTYPE_NONF_IPV4_UDP:
ice_pkt_insert_mac_addr(pkt, input->ext_data_outer.dst_mac);
@@ -1808,6 +1836,23 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct
ice_fdir_fltr *input,
input->ip.v6.proto);
ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
break;
+ case ICE_FLTR_PTYPE_FRAG_IPV4:
+ ice_pkt_insert_u32(loc, ICE_IPV4_DST_ADDR_OFFSET,
+ input->ip.v4.src_ip);
+ ice_pkt_insert_u32(loc, ICE_IPV4_SRC_ADDR_OFFSET,
+ input->ip.v4.dst_ip);
+ ice_pkt_insert_u8(loc, ICE_IPV4_TOS_OFFSET, input->ip.v4.tos);
+ ice_pkt_insert_u16(loc, ICE_IPV4_ID_OFFSET,
+ input->ip.v4.packet_id);
+ ice_pkt_insert_u8(loc, ICE_IPV4_TTL_OFFSET, input->ip.v4.ttl);
+ ice_pkt_insert_u8(loc, ICE_IPV4_PROTO_OFFSET,
+ input->ip.v4.proto);
+ ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
+ break;
+ case ICE_FLTR_PTYPE_FRAG_IPV6:
+ ice_pkt_insert_u32(loc, ICE_IPV6_ID_OFFSET,
+ input->ip.v6.packet_id);
+ break;
default:
return ICE_ERR_PARAM;
}
@@ -1838,7 +1883,8 @@ ice_fdir_get_prgm_pkt(struct ice_fdir_fltr *input, u8
*pkt, bool frag)
*/
bool ice_fdir_has_frag(enum ice_fltr_ptype flow)
{
- if (flow == ICE_FLTR_PTYPE_NONF_IPV4_OTHER)
+ if (flow == ICE_FLTR_PTYPE_FRAG_IPV4 ||
+ flow == ICE_FLTR_PTYPE_FRAG_IPV6)
return true;
else
return false;
diff --git a/drivers/net/ice/base/ice_fdir.h b/drivers/net/ice/base/ice_fdir.h
index 6573f96bc1..2acc1d6f1b 100644
--- a/drivers/net/ice/base/ice_fdir.h
+++ b/drivers/net/ice/base/ice_fdir.h
@@ -43,9 +43,11 @@
#define ICE_MAC_ETHTYPE_OFFSET 12
#define ICE_IPV4_TOS_OFFSET15
#define ICE_IPV
[dpdk-dev] [PATCH v5 3/3] net/ice: support FDIR for IP fragment packet
New FDIR parsing are added to handle the fragmented IPv4/IPv6 packet.
Signed-off-by: Jeff Guo
Signed-off-by: Ting Xu
---
drivers/net/ice/ice_fdir_filter.c | 116 ++---
drivers/net/ice/ice_generic_flow.c | 1 +
2 files changed, 106 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ice/ice_fdir_filter.c
b/drivers/net/ice/ice_fdir_filter.c
index 92e18d59cc..8158f75f05 100644
--- a/drivers/net/ice/ice_fdir_filter.c
+++ b/drivers/net/ice/ice_fdir_filter.c
@@ -24,7 +24,7 @@
#define ICE_FDIR_INSET_ETH_IPV4 (\
ICE_FDIR_INSET_ETH | \
ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | ICE_INSET_IPV4_TOS | \
- ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO)
+ ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO | ICE_INSET_IPV4_PKID)
#define ICE_FDIR_INSET_ETH_IPV4_UDP (\
ICE_FDIR_INSET_ETH_IPV4 | \
@@ -41,7 +41,8 @@
#define ICE_FDIR_INSET_ETH_IPV6 (\
ICE_INSET_DMAC | \
ICE_INSET_IPV6_SRC | ICE_INSET_IPV6_DST | ICE_INSET_IPV6_TC | \
- ICE_INSET_IPV6_HOP_LIMIT | ICE_INSET_IPV6_NEXT_HDR)
+ ICE_INSET_IPV6_HOP_LIMIT | ICE_INSET_IPV6_NEXT_HDR | \
+ ICE_INSET_IPV6_PKID)
#define ICE_FDIR_INSET_ETH_IPV6_UDP (\
ICE_FDIR_INSET_ETH_IPV6 | \
@@ -56,7 +57,8 @@
ICE_INSET_SCTP_SRC_PORT | ICE_INSET_SCTP_DST_PORT)
#define ICE_FDIR_INSET_IPV4 (\
- ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST)
+ ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | \
+ ICE_INSET_IPV4_PKID)
#define ICE_FDIR_INSET_IPV4_TCP (\
ICE_FDIR_INSET_IPV4 | \
@@ -95,6 +97,7 @@ static struct ice_pattern_match_item ice_fdir_pattern_list[]
= {
{pattern_eth_ipv4_tcp,
ICE_FDIR_INSET_ETH_IPV4_TCP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv4_sctp,
ICE_FDIR_INSET_ETH_IPV4_SCTP, ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6,
ICE_FDIR_INSET_ETH_IPV6,ICE_INSET_NONE, ICE_INSET_NONE},
+ {pattern_eth_ipv6_frag_ext,
ICE_FDIR_INSET_ETH_IPV6,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_udp,
ICE_FDIR_INSET_ETH_IPV6_UDP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_tcp,
ICE_FDIR_INSET_ETH_IPV6_TCP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_sctp,
ICE_FDIR_INSET_ETH_IPV6_SCTP, ICE_INSET_NONE, ICE_INSET_NONE},
@@ -882,11 +885,13 @@ ice_fdir_input_set_parse(uint64_t inset, enum
ice_flow_field *field)
{ICE_INSET_IPV4_TOS, ICE_FLOW_FIELD_IDX_IPV4_DSCP},
{ICE_INSET_IPV4_TTL, ICE_FLOW_FIELD_IDX_IPV4_TTL},
{ICE_INSET_IPV4_PROTO, ICE_FLOW_FIELD_IDX_IPV4_PROT},
+ {ICE_INSET_IPV4_PKID, ICE_FLOW_FIELD_IDX_IPV4_ID},
{ICE_INSET_IPV6_SRC, ICE_FLOW_FIELD_IDX_IPV6_SA},
{ICE_INSET_IPV6_DST, ICE_FLOW_FIELD_IDX_IPV6_DA},
{ICE_INSET_IPV6_TC, ICE_FLOW_FIELD_IDX_IPV6_DSCP},
{ICE_INSET_IPV6_NEXT_HDR, ICE_FLOW_FIELD_IDX_IPV6_PROT},
{ICE_INSET_IPV6_HOP_LIMIT, ICE_FLOW_FIELD_IDX_IPV6_TTL},
+ {ICE_INSET_IPV6_PKID, ICE_FLOW_FIELD_IDX_IPV6_ID},
{ICE_INSET_TCP_SRC_PORT, ICE_FLOW_FIELD_IDX_TCP_SRC_PORT},
{ICE_INSET_TCP_DST_PORT, ICE_FLOW_FIELD_IDX_TCP_DST_PORT},
{ICE_INSET_UDP_SRC_PORT, ICE_FLOW_FIELD_IDX_UDP_SRC_PORT},
@@ -936,6 +941,10 @@ ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow, struct
ice_flow_seg_info *seg)
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV4 |
ICE_FLOW_SEG_HDR_IPV_OTHER);
break;
+ case ICE_FLTR_PTYPE_FRAG_IPV4:
+ ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV4 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG);
+ break;
case ICE_FLTR_PTYPE_NONF_IPV6_UDP:
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_UDP |
ICE_FLOW_SEG_HDR_IPV6 |
@@ -955,6 +964,10 @@ ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow, struct
ice_flow_seg_info *seg)
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV6 |
ICE_FLOW_SEG_HDR_IPV_OTHER);
break;
+ case ICE_FLTR_PTYPE_FRAG_IPV6:
+ ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV6 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG);
+ break;
case ICE_FLTR_PTYPE_NONF_IPV4_UDP_VXLAN:
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_UDP |
ICE_FLOW_SEG_HDR_IPV4 |
@@ -1599,8 +1612,10 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter
*ad,
enum rte_flow_item_type l3 = RTE_FLOW_ITEM_TYPE_END;
enum ice_fdir_tunnel_type tunnel_type =
Re: [dpdk-dev] [PATCH v5 0/3] support flow for IP fragment in ICE
> -Original Message- > From: Guo, Jia > Sent: Tuesday, April 13, 2021 5:39 PM > To: Zhang, Qi Z ; Yang, Qiming > > Cc: dev@dpdk.org; Xu, Ting ; Guo, Jia > Subject: [PATCH v5 0/3] support flow for IP fragment in ICE > > Support RSS hash and FDIR for IP fragment packets in ICE PMD. > > v5: > rebase code. > v4: > correct typo when define fragment > v3: > rebase code and fix some parsing issues. > v2: > add some input check > > Jeff Guo (3): > net/ice/base: support IP fragment RSS and FDIR > net/ice: support RSS hash for IP fragment > net/ice: support FDIR for IP fragment packet > > drivers/net/ice/base/ice_fdir.c| 50 - > drivers/net/ice/base/ice_fdir.h| 22 +- > drivers/net/ice/base/ice_flow.c| 50 - > drivers/net/ice/base/ice_flow.h| 9 ++- > drivers/net/ice/base/ice_type.h| 1 + > drivers/net/ice/ice_fdir_filter.c | 116 ++--- > drivers/net/ice/ice_generic_flow.c | 22 ++ > drivers/net/ice/ice_generic_flow.h | 6 ++ > drivers/net/ice/ice_hash.c | 46 ++-- > 9 files changed, 293 insertions(+), 29 deletions(-) > > -- > 2.20.1 Reviewed-by: Ting Xu
Re: [dpdk-dev] [EXT] [PATCH] examples/l2fwd-crypto: remove key size validation
> In the example application the key can be provided by the user or
> generated randomly by the example application.
>
> Then a validation is done in order to check if the key size is
> supported in the algorithm capabilities.
>
> As a result of patch [1] application should support the case where a
> user supplies a wrapped key.
>
> In order to align with this patch and be able to use the app with
> wrapped keys, app should remove the validation of key size in the
> application and rely on a PMD key size validation.
>
> The validation is removed in case the key is provided by by user, and
> kept in case the key should be generated by the application.
>
> [1] https://www.mail-archive.com/dev@dpdk.org/msg201281.html
>
> Signed-off-by: Shiri Kuzin
> ---
This patch should be aligned as per the latest version of the patch.
http://patches.dpdk.org/project/dpdk/patch/20210413063718.3123698-1-ma...@nvidia.com/
> examples/l2fwd-crypto/main.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
> index a96cb94cc4..5ae2569065 100644
> --- a/examples/l2fwd-crypto/main.c
> +++ b/examples/l2fwd-crypto/main.c
> @@ -2111,13 +2111,11 @@ check_capabilities(struct l2fwd_crypto_options
> *options, uint8_t cdev_id)
> cap->sym.cipher.key_size.min,
> cap->sym.cipher.key_size.max,
> cap->sym.cipher.key_size.increment)
> - != 0) {
> + != 0)
> RTE_LOG(DEBUG, USER1,
> - "Device %u does not support cipher "
> - "key length\n",
> + "Key length does not match the
> device "
> + "%u capability\n",
> cdev_id);
> - return -1;
> - }
> /*
>* Check if length of the cipher key to be randomly generated
>* is supported by the algorithm chosen.
> --
> 2.21.0
Re: [dpdk-dev] [PATCH] examples/vhost: fix ioat ring space in callbacks
Hi,
> -Original Message-
> From: Maxime Coquelin
> Sent: Tuesday, April 13, 2021 4:51 PM
> To: Hu, Jiayu ; Jiang, Cheng1 ;
> Xia, Chenbo ; Thomas Monjalon
>
> Cc: dev@dpdk.org; Yang, YvonneX ; Wang, Yinan
> ; sta...@dpdk.org
> Subject: Re: [PATCH] examples/vhost: fix ioat ring space in callbacks
>
>
>
> On 4/7/21 9:54 AM, Hu, Jiayu wrote:
> > Hi Maxime,
> >
> >> -Original Message-
> >> From: Maxime Coquelin
> >> Sent: Wednesday, April 7, 2021 3:48 PM
> >> To: Jiang, Cheng1 ; Xia, Chenbo
> >> ; Thomas Monjalon
> >> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> >> ; Wang, Yinan ;
> >> sta...@dpdk.org
> >> Subject: Re: [PATCH] examples/vhost: fix ioat ring space in callbacks
> >>
> >>
> >>
> >> On 3/17/21 6:40 AM, Cheng Jiang wrote:
> >>> We use ioat ring space for determining if ioat callbacks can enqueue
> >>> a packet to ioat device. But there is one slot can't be used in ioat
> >>> ring due to the ioat driver design, so we need to reduce one slot in
> >>> ioat ring to prevent ring size mismatch in ioat callbacks.
> >>>
> >>> Fixes: 2aa47e94bfb2 ("examples/vhost: add ioat ring space count and
> >> check")
> >>> Cc: sta...@dpdk.org
> >>>
> >>> Signed-off-by: Cheng Jiang
> >>> ---
> >>> examples/vhost/ioat.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/examples/vhost/ioat.c b/examples/vhost/ioat.c index
> >>> 60b73be93..9cb5e0d50 100644
> >>> --- a/examples/vhost/ioat.c
> >>> +++ b/examples/vhost/ioat.c
> >>> @@ -113,7 +113,7 @@ open_ioat(const char *value)
> >>> goto out;
> >>> }
> >>> rte_rawdev_start(dev_id);
> >>> - cb_tracker[dev_id].ioat_space = IOAT_RING_SIZE;
> >>> + cb_tracker[dev_id].ioat_space = IOAT_RING_SIZE - 1;
> >>
> >> That really comforts me in thinking we need a generic abstraction for
> >> DMA devices. How is the application developer supposed to know that
> >> the DMA driver has such weird limitations?
> >>
> >> Can the driver be fixed to have a proper behavior?
> >
> > Here is the patch of providing capacity check API for DMA:
> > http://patches.dpdk.org/project/dpdk/patch/20210318182042.43658-6-
> bruc
> > e.richard...@intel.com/
>
> OK, thanks for the pointer.
>
> While this new API is being reviewed, and for LTS, let's pick your patch. As
> soon as Bruce patch is merged, please send a new patch on top to make use
> of this API.
Sure, thanks a lot.
Cheng
>
> Reviewed-by: Maxime Coquelin
>
> Thanks,
> Maxime
>
> > Thanks,
> > Jiayu
> >>
> >>> dma_info->nr++;
> >>> i++;
> >>> }
> >>>
> >
Re: [dpdk-dev] [EXT] [PATCH v3] cryptodev: formalize key wrap method in API
> The Key Wrap approach is used by applications in order to protect keys
> located in untrusted storage or transmitted over untrusted
> communications networks. The constructions are typically built from
> standard primitives such as block ciphers and cryptographic hash
> functions.
>
> The Key Wrap method and its parameters are a secret between the keys
> provider and the device, means that the device is preconfigured for
> this method using very secured way.
>
> The key wrap method may change the key length and layout.
>
> Add a description for the cipher transformation key to allow wrapped key
> to be forwarded by the same API.
>
> Add a new feature flag RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY to be
> enabled
> by PMDs support wrapped key in cipher trasformation.
>
> Signed-off-by: Matan Azrad
> ---
Acked-by: Akhil Goyal
I hope crypto mlx5 driver support this feature. Do not forget to add this flag
In that.
>
> V2:
> Address Akhil coment to introduce ne feature flag for wrapped keys.
>
> V3:
> Improve descriptions\spelling suggested by Akhil.
>
> doc/guides/cryptodevs/features/default.ini | 1 +
> doc/guides/cryptodevs/overview.rst | 3 +++
> doc/guides/rel_notes/release_21_05.rst | 5 +
> lib/librte_cryptodev/rte_crypto_sym.h | 8
> lib/librte_cryptodev/rte_cryptodev.c | 2 ++
> lib/librte_cryptodev/rte_cryptodev.h | 2 ++
> 6 files changed, 21 insertions(+)
>
> diff --git a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index 978bb30cc1..c24814de98 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -32,6 +32,7 @@ Symmetric sessionless =
> Non-Byte aligned data =
> Sym raw data path API =
> Cipher multiple data units =
> +Cipher wrapped key =
>
> ;
> ; Supported crypto algorithms of a default crypto driver.
> diff --git a/doc/guides/cryptodevs/overview.rst
> b/doc/guides/cryptodevs/overview.rst
> index e24e3e1993..b87c4c6a27 100644
> --- a/doc/guides/cryptodevs/overview.rst
> +++ b/doc/guides/cryptodevs/overview.rst
> @@ -49,6 +49,9 @@ Supported Feature Flags
> - "CIPHER_MULTIPLE_DATA_UNITS" feature flag means PMD support
> operations
>on multiple data-units message.
>
> + - "CIPHER_WRAPPED_KEY" feature flag means PMD support wrapped key
> in cipher
> + xform.
> +
>
> Supported Cipher Algorithms
> ---
> diff --git a/doc/guides/rel_notes/release_21_05.rst
> b/doc/guides/rel_notes/release_21_05.rst
> index 1537fac4bc..24b8b28253 100644
> --- a/doc/guides/rel_notes/release_21_05.rst
> +++ b/doc/guides/rel_notes/release_21_05.rst
> @@ -132,6 +132,11 @@ New Features
>data-units for AES-XTS algorithm, the data-unit length should be set in the
>transformation. A capability for it was added too.
>
> +* **Added a crypto PMD feature flag to support cipher wrapped keys.**
> +
> + A new feature flag is added to allow application to provide cipher wrapped
> + keys in session xforms.
> +
>
> Removed Items
> -
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> b/lib/librte_cryptodev/rte_crypto_sym.h
> index 5973e31f30..a1fb5b0f5c 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -200,6 +200,14 @@ struct rte_crypto_cipher_xform {
> uint16_t length;/**< key length in bytes */
> } key;
> /**< Cipher key
> + *
> + * In case the PMD supports
> RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY, the
> + * original key data provided may be wrapped(encrypted) using key
> wrap
> + * algorithm such as AES key wrap (rfc3394) and hence length of the
> key
> + * may increase beyond the PMD advertised supported key size.
> + * PMD shall validate the key length and report EMSGSIZE error while
> + * configuring the session and application can skip checking the
> + * capability key length in such cases.
>*
>* For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data
> will
>* point to a concatenation of the AES encryption key followed by a
> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> b/lib/librte_cryptodev/rte_cryptodev.c
> index e02e001325..a84cd745f9 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.c
> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> @@ -619,6 +619,8 @@ rte_cryptodev_get_feature_name(uint64_t flag)
> return "NON_BYTE_ALIGNED_DATA";
> case RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS:
> return "CIPHER_MULTIPLE_DATA_UNITS";
> + case RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY:
> + return "CIPHER_WRAPPED_KEY";
> default:
> return NULL;
> }
> diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> b/lib/librte_cryptodev/rte_cryptodev.h
> index c274e208ed..a823831065 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -47
Re: [dpdk-dev] [PATCH] common/sfc_efx/base: fix indication of MAE encap. support
On 4/10/2021 1:51 AM, Ivan Malov wrote:
The indication fields in the MCDI response are individual
bits, but the current code mistakenly compares the larger
dword with 1. This breaks encap. type discovery. Fix that.
Fixes: 891408c45a63 ("common/sfc_efx/base: indicate MAE support for
encapsulation")
Cc: sta...@dpdk.org
Signed-off-by: Ivan Malov
Reviewed-by: Andrew Rybchenko
Reviewed-by: Andy Moreton
Applied to dpdk-next-net/main, thanks.
Re: [dpdk-dev] [PATCH] drivers: add missing headers
On 3/26/2021 4:46 PM, Ferruh Yigit wrote: These headers are used but not included explicitly, including them. "arpa/inet.h" is included for 'htons' and friends. "netinet/in.h" is included for 'IPPROTO_IP'. Signed-off-by: Ferruh Yigit Any comment/review?
Re: [dpdk-dev] [EXT] [PATCH v3 0/8] baseband: add NXP LA12xx driver
Hi Nicholas, Could you please review this series? Regards, Akhil > This series introduces the BBDEV LA12xx poll mode driver (PMD) to support > an implementation for offloading High Phy processing functions like > LDPC Encode / Decode 5GNR wireless acceleration function, using PCI based > LA12xx Software defined radio. > > Please check the documentation patch for more info. > > The driver currently implements basic feature to offload only the 5G LDPC > encode/decode. > > Modifications has been done in test vectors to optionally support input in > network byte order. Two test vectors are also added as an example with > input data in network byte. > > v2: add test case changes > v3: fix 32 bit compilation > > Hemant Agrawal (6): > baseband: introduce NXP LA12xx driver > baseband/la12xx: add devargs for max queues > baseband/la12xx: add support for multiple modems > baseband/la12xx: add queue and modem config support > baseband/la12xx: add enqueue and dequeue support > baseband/la12xx: add documentation support > > Nipun Gupta (2): > app/bbdev: add parameter to take input in network order > app/bbdev: add test vectors for transport blocks > > MAINTAINERS |9 + > app/test-bbdev/test_bbdev_vector.c| 18 +- > app/test-bbdev/test_bbdev_vector.h|2 + > app/test-bbdev/test_vectors/ldpc_dec_tb.data | 362 + > app/test-bbdev/test_vectors/ldpc_enc_tb.data | 482 +++ > doc/guides/bbdevs/features/la12xx.ini | 14 + > doc/guides/bbdevs/index.rst |1 + > doc/guides/bbdevs/la12xx.rst | 139 ++ > doc/guides/rel_notes/release_21_05.rst|5 + > drivers/baseband/la12xx/bbdev_la12xx.c| 1178 + > drivers/baseband/la12xx/bbdev_la12xx.h| 57 + > drivers/baseband/la12xx/bbdev_la12xx_ipc.h| 237 > .../baseband/la12xx/bbdev_la12xx_pmd_logs.h | 38 + > drivers/baseband/la12xx/meson.build |6 + > drivers/baseband/la12xx/version.map |3 + > drivers/baseband/meson.build |2 +- > 16 files changed, 2550 insertions(+), 3 deletions(-) > create mode 100644 app/test-bbdev/test_vectors/ldpc_dec_tb.data > create mode 100644 app/test-bbdev/test_vectors/ldpc_enc_tb.data > create mode 100644 doc/guides/bbdevs/features/la12xx.ini > create mode 100644 doc/guides/bbdevs/la12xx.rst > create mode 100644 drivers/baseband/la12xx/bbdev_la12xx.c > create mode 100644 drivers/baseband/la12xx/bbdev_la12xx.h > create mode 100644 drivers/baseband/la12xx/bbdev_la12xx_ipc.h > create mode 100644 drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h > create mode 100644 drivers/baseband/la12xx/meson.build > create mode 100644 drivers/baseband/la12xx/version.map > > -- > 2.17.1
[dpdk-dev] [PATCH v6 3/3] net/ice: support FDIR for IP fragment packet
New FDIR parsing are added to handle the fragmented IPv4/IPv6 packet.
Signed-off-by: Jeff Guo
Signed-off-by: Ting Xu
Reviewed-by: Ting Xu
---
drivers/net/ice/ice_fdir_filter.c | 118 ++---
drivers/net/ice/ice_generic_flow.c | 1 +
2 files changed, 107 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ice/ice_fdir_filter.c
b/drivers/net/ice/ice_fdir_filter.c
index 92e18d59cc..8a01c8c997 100644
--- a/drivers/net/ice/ice_fdir_filter.c
+++ b/drivers/net/ice/ice_fdir_filter.c
@@ -24,7 +24,7 @@
#define ICE_FDIR_INSET_ETH_IPV4 (\
ICE_FDIR_INSET_ETH | \
ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | ICE_INSET_IPV4_TOS | \
- ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO)
+ ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO | ICE_INSET_IPV4_PKID)
#define ICE_FDIR_INSET_ETH_IPV4_UDP (\
ICE_FDIR_INSET_ETH_IPV4 | \
@@ -41,7 +41,8 @@
#define ICE_FDIR_INSET_ETH_IPV6 (\
ICE_INSET_DMAC | \
ICE_INSET_IPV6_SRC | ICE_INSET_IPV6_DST | ICE_INSET_IPV6_TC | \
- ICE_INSET_IPV6_HOP_LIMIT | ICE_INSET_IPV6_NEXT_HDR)
+ ICE_INSET_IPV6_HOP_LIMIT | ICE_INSET_IPV6_NEXT_HDR | \
+ ICE_INSET_IPV6_PKID)
#define ICE_FDIR_INSET_ETH_IPV6_UDP (\
ICE_FDIR_INSET_ETH_IPV6 | \
@@ -56,7 +57,8 @@
ICE_INSET_SCTP_SRC_PORT | ICE_INSET_SCTP_DST_PORT)
#define ICE_FDIR_INSET_IPV4 (\
- ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST)
+ ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | \
+ ICE_INSET_IPV4_PKID)
#define ICE_FDIR_INSET_IPV4_TCP (\
ICE_FDIR_INSET_IPV4 | \
@@ -95,6 +97,7 @@ static struct ice_pattern_match_item ice_fdir_pattern_list[]
= {
{pattern_eth_ipv4_tcp,
ICE_FDIR_INSET_ETH_IPV4_TCP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv4_sctp,
ICE_FDIR_INSET_ETH_IPV4_SCTP, ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6,
ICE_FDIR_INSET_ETH_IPV6,ICE_INSET_NONE, ICE_INSET_NONE},
+ {pattern_eth_ipv6_frag_ext,
ICE_FDIR_INSET_ETH_IPV6,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_udp,
ICE_FDIR_INSET_ETH_IPV6_UDP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_tcp,
ICE_FDIR_INSET_ETH_IPV6_TCP,ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_sctp,
ICE_FDIR_INSET_ETH_IPV6_SCTP, ICE_INSET_NONE, ICE_INSET_NONE},
@@ -882,11 +885,13 @@ ice_fdir_input_set_parse(uint64_t inset, enum
ice_flow_field *field)
{ICE_INSET_IPV4_TOS, ICE_FLOW_FIELD_IDX_IPV4_DSCP},
{ICE_INSET_IPV4_TTL, ICE_FLOW_FIELD_IDX_IPV4_TTL},
{ICE_INSET_IPV4_PROTO, ICE_FLOW_FIELD_IDX_IPV4_PROT},
+ {ICE_INSET_IPV4_PKID, ICE_FLOW_FIELD_IDX_IPV4_ID},
{ICE_INSET_IPV6_SRC, ICE_FLOW_FIELD_IDX_IPV6_SA},
{ICE_INSET_IPV6_DST, ICE_FLOW_FIELD_IDX_IPV6_DA},
{ICE_INSET_IPV6_TC, ICE_FLOW_FIELD_IDX_IPV6_DSCP},
{ICE_INSET_IPV6_NEXT_HDR, ICE_FLOW_FIELD_IDX_IPV6_PROT},
{ICE_INSET_IPV6_HOP_LIMIT, ICE_FLOW_FIELD_IDX_IPV6_TTL},
+ {ICE_INSET_IPV6_PKID, ICE_FLOW_FIELD_IDX_IPV6_ID},
{ICE_INSET_TCP_SRC_PORT, ICE_FLOW_FIELD_IDX_TCP_SRC_PORT},
{ICE_INSET_TCP_DST_PORT, ICE_FLOW_FIELD_IDX_TCP_DST_PORT},
{ICE_INSET_UDP_SRC_PORT, ICE_FLOW_FIELD_IDX_UDP_SRC_PORT},
@@ -936,6 +941,10 @@ ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow, struct
ice_flow_seg_info *seg)
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV4 |
ICE_FLOW_SEG_HDR_IPV_OTHER);
break;
+ case ICE_FLTR_PTYPE_FRAG_IPV4:
+ ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV4 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG);
+ break;
case ICE_FLTR_PTYPE_NONF_IPV6_UDP:
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_UDP |
ICE_FLOW_SEG_HDR_IPV6 |
@@ -955,6 +964,10 @@ ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow, struct
ice_flow_seg_info *seg)
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV6 |
ICE_FLOW_SEG_HDR_IPV_OTHER);
break;
+ case ICE_FLTR_PTYPE_FRAG_IPV6:
+ ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV6 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG);
+ break;
case ICE_FLTR_PTYPE_NONF_IPV4_UDP_VXLAN:
ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_UDP |
ICE_FLOW_SEG_HDR_IPV4 |
@@ -1599,8 +1612,10 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter
*ad,
enum rte_flow_item_type l3 = RTE_FLOW_ITEM_TYPE_END;
enum ice_fdir_tun
[dpdk-dev] [PATCH v6 0/3] support flow for IP fragment in ICE
Support RSS hash and FDIR for IP fragment packets in ICE PMD. v6: fix uninitialize issue v5: rebase code. v4: correct typo when define fragment v3: rebase code and fix some parsing issues. v2: add some input check Jeff Guo (3): net/ice/base: support IP fragment RSS and FDIR net/ice: support RSS hash for IP fragment net/ice: support FDIR for IP fragment packet drivers/net/ice/base/ice_fdir.c| 50 +++- drivers/net/ice/base/ice_fdir.h| 22 +- drivers/net/ice/base/ice_flow.c| 50 +++- drivers/net/ice/base/ice_flow.h| 9 ++- drivers/net/ice/base/ice_type.h| 1 + drivers/net/ice/ice_fdir_filter.c | 118 ++--- drivers/net/ice/ice_generic_flow.c | 22 ++ drivers/net/ice/ice_generic_flow.h | 6 ++ drivers/net/ice/ice_hash.c | 46 +-- 9 files changed, 294 insertions(+), 30 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH v6 1/3] net/ice/base: support IP fragment RSS and FDIR
Add support for IP fragment RSS hash and FDIR according to packet ID.
Separate IP fragment and IP other packet types.
Signed-off-by: Ting Xu
Signed-off-by: Jeff Guo
---
drivers/net/ice/base/ice_fdir.c | 50 +++--
drivers/net/ice/base/ice_fdir.h | 22 ---
drivers/net/ice/base/ice_flow.c | 50 -
drivers/net/ice/base/ice_flow.h | 9 --
drivers/net/ice/base/ice_type.h | 1 +
5 files changed, 122 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ice/base/ice_fdir.c b/drivers/net/ice/base/ice_fdir.c
index 8f9c0d346b..c1b14783ac 100644
--- a/drivers/net/ice/base/ice_fdir.c
+++ b/drivers/net/ice/base/ice_fdir.c
@@ -518,6 +518,24 @@ static const u8 ice_fdir_ipv4_udp_ecpri_tp0_pkt[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};
+static const u8 ice_fdir_ipv6_frag_pkt[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x86, 0xDD, 0x60, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x2C, 0x40, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3B, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+};
+
+static const u8 ice_fdir_ipv4_frag_pkt[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x45, 0x00,
+ 0x00, 0x14, 0x00, 0x00, 0x20, 0x00, 0x40, 0x10,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00
+};
static const u8 ice_fdir_tcpv6_pkt[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x86, 0xDD, 0x60, 0x00,
@@ -716,6 +734,16 @@ static const struct ice_fdir_base_pkt ice_fdir_pkt[] = {
sizeof(ice_fdir_ipv4_pkt), ice_fdir_ipv4_pkt,
sizeof(ice_fdir_ip4_tun_pkt), ice_fdir_ip4_tun_pkt,
},
+ {
+ ICE_FLTR_PTYPE_FRAG_IPV4,
+ sizeof(ice_fdir_ipv4_frag_pkt), ice_fdir_ipv4_frag_pkt,
+ sizeof(ice_fdir_ipv4_frag_pkt), ice_fdir_ipv4_frag_pkt,
+ },
+ {
+ ICE_FLTR_PTYPE_FRAG_IPV6,
+ sizeof(ice_fdir_ipv6_frag_pkt), ice_fdir_ipv6_frag_pkt,
+ sizeof(ice_fdir_ipv6_frag_pkt), ice_fdir_ipv6_frag_pkt,
+ },
{
ICE_FLTR_PTYPE_NONF_IPV4_GTPU,
sizeof(ice_fdir_ipv4_gtpu4_pkt),
@@ -1505,7 +1533,7 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct
ice_fdir_fltr *input,
ice_pkt_insert_u8(loc, ICE_IPV4_TTL_OFFSET, input->ip.v4.ttl);
ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
if (frag)
- loc[20] = ICE_FDIR_IPV4_PKT_FLAG_DF;
+ loc[20] = ICE_FDIR_IPV4_PKT_FLAG_MF;
break;
case ICE_FLTR_PTYPE_NONF_IPV4_UDP:
ice_pkt_insert_mac_addr(pkt, input->ext_data_outer.dst_mac);
@@ -1808,6 +1836,23 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct
ice_fdir_fltr *input,
input->ip.v6.proto);
ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
break;
+ case ICE_FLTR_PTYPE_FRAG_IPV4:
+ ice_pkt_insert_u32(loc, ICE_IPV4_DST_ADDR_OFFSET,
+ input->ip.v4.src_ip);
+ ice_pkt_insert_u32(loc, ICE_IPV4_SRC_ADDR_OFFSET,
+ input->ip.v4.dst_ip);
+ ice_pkt_insert_u8(loc, ICE_IPV4_TOS_OFFSET, input->ip.v4.tos);
+ ice_pkt_insert_u16(loc, ICE_IPV4_ID_OFFSET,
+ input->ip.v4.packet_id);
+ ice_pkt_insert_u8(loc, ICE_IPV4_TTL_OFFSET, input->ip.v4.ttl);
+ ice_pkt_insert_u8(loc, ICE_IPV4_PROTO_OFFSET,
+ input->ip.v4.proto);
+ ice_pkt_insert_mac_addr(loc, input->ext_data.dst_mac);
+ break;
+ case ICE_FLTR_PTYPE_FRAG_IPV6:
+ ice_pkt_insert_u32(loc, ICE_IPV6_ID_OFFSET,
+ input->ip.v6.packet_id);
+ break;
default:
return ICE_ERR_PARAM;
}
@@ -1838,7 +1883,8 @@ ice_fdir_get_prgm_pkt(struct ice_fdir_fltr *input, u8
*pkt, bool frag)
*/
bool ice_fdir_has_frag(enum ice_fltr_ptype flow)
{
- if (flow == ICE_FLTR_PTYPE_NONF_IPV4_OTHER)
+ if (flow == ICE_FLTR_PTYPE_FRAG_IPV4 ||
+ flow == ICE_FLTR_PTYPE_FRAG_IPV6)
return true;
else
return false;
diff --git a/drivers/net/ice/base/ice_fdir.h b/drivers/net/ice/base/ice_fdir.h
index 6573f96bc1..2acc1d6f1b 100644
--- a/drivers/net/ice/base/ice_fdir.h
+++ b/drivers/net/ice/base/ice_fdir.h
@@ -43,9 +43,11 @@
#define ICE_MAC_ETHTYPE_OFFSET 12
#define ICE_IPV4_TOS_OFFSET15
#define ICE_IPV
[dpdk-dev] [PATCH v6 2/3] net/ice: support RSS hash for IP fragment
New pattern and RSS hash flow parsing are added to handle fragmented
IPv4/IPv6 packet.
Signed-off-by: Jeff Guo
---
drivers/net/ice/ice_generic_flow.c | 21 ++
drivers/net/ice/ice_generic_flow.h | 6
drivers/net/ice/ice_hash.c | 46 --
3 files changed, 65 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ice/ice_generic_flow.c
b/drivers/net/ice/ice_generic_flow.c
index 8704812622..2389bc6637 100644
--- a/drivers/net/ice/ice_generic_flow.c
+++ b/drivers/net/ice/ice_generic_flow.c
@@ -212,6 +212,27 @@ enum rte_flow_item_type pattern_eth_qinq_ipv6[] = {
RTE_FLOW_ITEM_TYPE_IPV6,
RTE_FLOW_ITEM_TYPE_END,
};
+enum rte_flow_item_type pattern_eth_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+enum rte_flow_item_type pattern_eth_vlan_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+enum rte_flow_item_type pattern_eth_qinq_ipv6_frag_ext[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT,
+ RTE_FLOW_ITEM_TYPE_END,
+};
enum rte_flow_item_type pattern_eth_ipv6_udp[] = {
RTE_FLOW_ITEM_TYPE_ETH,
RTE_FLOW_ITEM_TYPE_IPV6,
diff --git a/drivers/net/ice/ice_generic_flow.h
b/drivers/net/ice/ice_generic_flow.h
index 9f422e5925..2afe719264 100644
--- a/drivers/net/ice/ice_generic_flow.h
+++ b/drivers/net/ice/ice_generic_flow.h
@@ -52,6 +52,7 @@
#define ICE_L2TPV3OIP_SESSION_ID BIT_ULL(43)
#define ICE_PFCP_SEID BIT_ULL(42)
#define ICE_PFCP_S_FIELD BIT_ULL(41)
+#define ICE_IP_PK_ID BIT_ULL(40)
/* input set */
@@ -69,11 +70,13 @@
#define ICE_INSET_IPV4_TOS (ICE_PROT_IPV4 | ICE_IP_TOS)
#define ICE_INSET_IPV4_PROTO (ICE_PROT_IPV4 | ICE_IP_PROTO)
#define ICE_INSET_IPV4_TTL (ICE_PROT_IPV4 | ICE_IP_TTL)
+#define ICE_INSET_IPV4_PKID(ICE_PROT_IPV4 | ICE_IP_PK_ID)
#define ICE_INSET_IPV6_SRC (ICE_PROT_IPV6 | ICE_IP_SRC)
#define ICE_INSET_IPV6_DST (ICE_PROT_IPV6 | ICE_IP_DST)
#define ICE_INSET_IPV6_NEXT_HDR(ICE_PROT_IPV6 | ICE_IP_PROTO)
#define ICE_INSET_IPV6_HOP_LIMIT (ICE_PROT_IPV6 | ICE_IP_TTL)
#define ICE_INSET_IPV6_TC (ICE_PROT_IPV6 | ICE_IP_TOS)
+#define ICE_INSET_IPV6_PKID(ICE_PROT_IPV6 | ICE_IP_PK_ID)
#define ICE_INSET_TCP_SRC_PORT (ICE_PROT_TCP | ICE_SPORT)
#define ICE_INSET_TCP_DST_PORT (ICE_PROT_TCP | ICE_DPORT)
@@ -202,6 +205,9 @@ extern enum rte_flow_item_type pattern_eth_qinq_ipv4_icmp[];
extern enum rte_flow_item_type pattern_eth_ipv6[];
extern enum rte_flow_item_type pattern_eth_vlan_ipv6[];
extern enum rte_flow_item_type pattern_eth_qinq_ipv6[];
+extern enum rte_flow_item_type pattern_eth_ipv6_frag_ext[];
+extern enum rte_flow_item_type pattern_eth_vlan_ipv6_frag_ext[];
+extern enum rte_flow_item_type pattern_eth_qinq_ipv6_frag_ext[];
extern enum rte_flow_item_type pattern_eth_ipv6_udp[];
extern enum rte_flow_item_type pattern_eth_vlan_ipv6_udp[];
extern enum rte_flow_item_type pattern_eth_qinq_ipv6_udp[];
diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
index e56cdf9941..75b6947625 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -47,8 +47,10 @@
ETH_RSS_NONFRAG_IPV6_TCP | \
ETH_RSS_NONFRAG_IPV6_SCTP)
-#define VALID_RSS_IPV4 (ETH_RSS_IPV4 | VALID_RSS_IPV4_L4)
-#define VALID_RSS_IPV6 (ETH_RSS_IPV6 | VALID_RSS_IPV6_L4)
+#define VALID_RSS_IPV4 (ETH_RSS_IPV4 | ETH_RSS_FRAG_IPV4 | \
+VALID_RSS_IPV4_L4)
+#define VALID_RSS_IPV6 (ETH_RSS_IPV6 | ETH_RSS_FRAG_IPV6 | \
+VALID_RSS_IPV6_L4)
#define VALID_RSS_L3 (VALID_RSS_IPV4 | VALID_RSS_IPV6)
#define VALID_RSS_L4 (VALID_RSS_IPV4_L4 | VALID_RSS_IPV6_L4)
@@ -108,6 +110,7 @@ ice_hash_parse_pattern_action(struct ice_adapter *ad,
/* Rss configuration template */
struct ice_rss_hash_cfg ipv4_tmplt = {
ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG |
ICE_FLOW_SEG_HDR_IPV_OTHER,
ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV4,
ICE_RSS_OUTER_HEADERS,
@@ -146,6 +149,15 @@ struct ice_rss_hash_cfg ipv6_tmplt = {
0
};
+struct ice_rss_hash_cfg ipv6_frag_tmplt = {
+ ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV6 |
+ ICE_FLOW_SEG_HDR_IPV_FRAG |
+ ICE_FLOW_SEG_HDR_IPV_OTHER,
+ ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV6,
+ ICE_RSS_ANY_HEADERS,
+ 0
+};
+
struct ice_rss_hash_cf
Re: [dpdk-dev] [EXT] [dpdk-dev v2] cryptodev: change raw data path dequeue API
Hi Fan,
> This patch changes the experimental raw data path dequeue burst API.
> Originally the API enforces the user to provide callback function
> to get maximum dequeue count. This change gives the user one more
> option to pass directly the expected dequeue count.
>
> Signed-off-by: Fan Zhang
> ---
> app/test/test_cryptodev.c | 8 +---
> doc/guides/rel_notes/release_21_05.rst | 3 +++
> drivers/crypto/qat/qat_sym_hw_dp.c | 21 ++---
> lib/librte_cryptodev/rte_cryptodev.c | 5 +++--
> lib/librte_cryptodev/rte_cryptodev.h | 8
> 5 files changed, 33 insertions(+), 12 deletions(-)
>
> diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
> index f91debc168..a910547423 100644
> --- a/app/test/test_cryptodev.c
> +++ b/app/test/test_cryptodev.c
> @@ -162,12 +162,6 @@ ceil_byte_length(uint32_t num_bits)
> return (num_bits >> 3);
> }
>
> -static uint32_t
> -get_raw_dp_dequeue_count(void *user_data __rte_unused)
> -{
> - return 1;
> -}
> -
> static void
> post_process_raw_dp_op(void *user_data, uint32_t index __rte_unused,
> uint8_t is_op_success)
> @@ -345,7 +339,7 @@ process_sym_raw_dp_op(uint8_t dev_id, uint16_t
> qp_id,
> n = n_success = 0;
> while (count++ < MAX_RAW_DEQUEUE_COUNT && n == 0) {
> n = rte_cryptodev_raw_dequeue_burst(ctx,
> - get_raw_dp_dequeue_count,
> post_process_raw_dp_op,
> + NULL, 1, post_process_raw_dp_op,
> (void **)&ret_op, 0, &n_success,
> &dequeue_status);
> if (dequeue_status < 0) {
> diff --git a/doc/guides/rel_notes/release_21_05.rst
> b/doc/guides/rel_notes/release_21_05.rst
> index 8e686cc627..943f1596c5 100644
> --- a/doc/guides/rel_notes/release_21_05.rst
> +++ b/doc/guides/rel_notes/release_21_05.rst
> @@ -130,6 +130,9 @@ API Changes
> Also, make sure to start the actual text at the margin.
> ===
>
> +* cryptodev: the function ``rte_cryptodev_raw_dequeue_burst`` is added a
> + parameter ``max_nb_to_dequeue`` to give user a more flexible dequeue
> control.
> +
Shouldn't we remove the callback completely?
What is the use case of having 2 different methods of passing a
Simple dequeue count?
Why do we need such flexibility?
Regards,
Akhil
Re: [dpdk-dev] [PATCH v2 1/2] ethdev: add packet integrity checks
> -Original Message- > From: Ferruh Yigit > Sent: Tuesday, April 13, 2021 11:30 AM > > On 4/13/2021 9:18 AM, Ori Kam wrote: > > Hi Ferruh, > > > >> -Original Message- > >> From: Ferruh Yigit > >> Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks > >> > >> On 4/13/2021 8:12 AM, Ori Kam wrote: > >>> Hi Ferruh, > >>> > -Original Message- > From: Ferruh Yigit > Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks > > On 4/12/2021 8:26 PM, Ori Kam wrote: > > Hi Ferruh, > > > >> -Original Message- > >> From: Ferruh Yigit > >> Subject: Re: [PATCH v2 1/2] ethdev: add packet integrity checks > >> > >> On 4/11/2021 6:34 PM, Gregory Etelson wrote: > >>> From: Ori Kam > >>> > >>> Currently, DPDK application can offload the checksum check, > >>> and report it in the mbuf. > >>> > >>> However, as more and more applications are offloading some or all > >>> logic and action to the HW, there is a need to check the packet > >>> integrity so the right decision can be taken. > >>> > >>> The application logic can be positive meaning if the packet is > >>> valid jump / do actions, or negative if packet is not valid > >>> jump to SW / do actions (like drop) a, and add default flow > >>> (match all in low priority) that will direct the miss packet > >>> to the miss path. > >>> > >>> Since currenlty rte_flow works in positive way the assumtion is > >>> that the postive way will be the common way in this case also. > >>> > >>> When thinking what is the best API to implement such feature, > >>> we need to considure the following (in no specific order): > >>> 1. API breakage. > >>> 2. Simplicity. > >>> 3. Performance. > >>> 4. HW capabilities. > >>> 5. rte_flow limitation. > >>> 6. Flexability. > >>> > >>> First option: Add integrity flags to each of the items. > >>> For example add checksum_ok to ipv4 item. > >>> > >>> Pros: > >>> 1. No new rte_flow item. > >>> 2. Simple in the way that on each item the app can see > >>> what checks are available. > >>> > >>> Cons: > >>> 1. API breakage. > >>> 2. increase number of flows, since app can't add global rule and > >>>must have dedicated flow for each of the flow combinations, for > example > >>>matching on icmp traffic or UDP/TCP traffic with IPv4 / IPv6 > >>> will > >>>result in 5 flows. > >>> > >>> Second option: dedicated item > >>> > >>> Pros: > >>> 1. No API breakage, and there will be no for some time due to having > >>>extra space. (by using bits) > >>> 2. Just one flow to support the icmp or UDP/TCP traffic with IPv4 / > >>>IPv6. > >>> 3. Simplicity application can just look at one place to see all > >>> possible > >>>checks. > >>> 4. Allow future support for more tests. > >>> > >>> Cons: > >>> 1. New item, that holds number of fields from different items. > >>> > >>> For starter the following bits are suggested: > >>> 1. packet_ok - means that all HW checks depending on packet layer > have > >>>passed. This may mean that in some HW such flow should be > splited > >> to > >>>number of flows or fail. > >>> 2. l2_ok - all check flor layer 2 have passed. > >>> 3. l3_ok - all check flor layer 2 have passed. If packet doens't have > >>>l3 layer this check shoudl fail. > >>> 4. l4_ok - all check flor layer 2 have passed. If packet doesn't > >>>have l4 layer this check should fail. > >>> 5. l2_crc_ok - the layer 2 crc is O.K. it is possible that the crc > >>> will > >>>be O.K. but the l3_ok will be 0. it is not possible that > >>> l2_crc_ok will > >>>be 0 and the l3_ok will be 0. > >>> 6. ipv4_csum_ok - IPv4 checksum is O.K. > >>> 7. l4_csum_ok - layer 4 checksum is O.K. > >>> 8. l3_len_OK - check that the reported layer 3 len is smaller than the > >>>packet len. > >>> > >>> Example of usage: > >>> 1. check packets from all possible layers for integrity. > >>>flow create integrity spec packet_ok = 1 mask packet_ok = 1 > >>> . > >>> > >>> 2. Check only packet with layer 4 (UDP / TCP) > >>>flow create integrity spec l3_ok = 1, l4_ok = 1 mask l3_ok = 1 > l4_ok = > >> 1 > >>> > >> > >> Hi Ori, > >> > >> Is the intention of the API just filtering, like apply some action to > >> the > >> packets based on their integration status. Like drop packets their > >> l2_crc > >> checksum failed? Here configuration is done by existing offload APIs. > >> > >> Or is the intention to configure the integration check on NIC, like to > >> say > >> enable layer 2 checks, and
Re: [dpdk-dev] [PATCH] net/i40e: add Tx preparation for vector data path
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Friday, April 9, 2021 6:40 PM
> To: Rong, Leyi ; Yigit, Ferruh ;
> Zhang, Qi Z ; Xing, Beilei
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] net/i40e: add Tx preparation for vector data
> path
>
>
>
> > > > > > Fill up dev->tx_pkt_prepare to i40e_pkt_prepare when on vector
> > > > > > and simple data path selection, as the sanity check is needed
> > > > > > ideally.
> > > > > >
> > > > > > Signed-off-by: Leyi Rong
> > > > > > ---
> > > > > > drivers/net/i40e/i40e_rxtx.c | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/net/i40e/i40e_rxtx.c
> > > > > > b/drivers/net/i40e/i40e_rxtx.c index 61cb204be2..b3d7765e3b
> > > > > > 100644
> > > > > > --- a/drivers/net/i40e/i40e_rxtx.c
> > > > > > +++ b/drivers/net/i40e/i40e_rxtx.c
> > > > > > @@ -3412,7 +3412,7 @@ i40e_set_tx_function(struct rte_eth_dev
> *dev)
> > > > > > PMD_INIT_LOG(DEBUG, "Simple tx finally be
> used.");
> > > > > > dev->tx_pkt_burst = i40e_xmit_pkts_simple;
> > > > > > }
> > > > > > - dev->tx_pkt_prepare = NULL;
> > > > > > + dev->tx_pkt_prepare = i40e_prep_pkts;
> > > > > > } else {
> > > > > > PMD_INIT_LOG(DEBUG, "Xmit tx finally be used.");
> > > > > > dev->tx_pkt_burst = i40e_xmit_pkts;
> > > > > >
> > > > >
> > > > > It seems prepare function is doing some sanity checks before
> > > > > handing packets to the HW.
> > > > > So with this change all Tx paths calls the same Tx prepare
> > > > > function, if so why not set the function pointer outside of the
> > > > > if block, instead of setting it in both legs of the if/else?
> > > > > This clarifies that Tx prepare
> > > used always.
> > > >
> > > > Hi Ferruh,
> > > >
> > > > Yes, it make sense.
> > > >
> > > > Hi Konstantin,
> > >
> > > Hi Leyi,
> > >
> > > >
> > > > Would that be something wrong if the prepare function goes for
> > > > simple Tx
> > > function although it does not support the offload feature yet?
> > > >
> > >
> > > Current situation:
> > > For simple TX path we set dev->tx_pkt_prepare = NULL.
> > > That makes rte_eth_tx_prepare() a stub that does nothing and always
> returns:
> > > "All packets are good".
> > > That is unsafe off-course, and if upper layer will pass a packet
> > > that is not supported, then it can lead to various bad things: bad
> > > cksum, corrupted packets, TX hang, etc.
> > > But at least it keeps simple TX path fast.
> > > With that patch:
> > > For simple TX path we set dev->tx_pkt_prepare = i40e_prep_pkts.
> > > Now on TX path we invoke extra function that does a lot of checks,
> > > but it still
> > > unsafe:
> > > as i40e_prep_pkts() assumes that full-featured TX function is in
> > > place (multi-segs are allowed, etc.).
> > > So our simple TX path became slower, but still is unsafe.
> > > I think that if we want to introduce tx_prepare() for simple TX
> > > path, then the proper way - create a new function for it
> (i40e_simple_prep_pkts() or so).
> > > It will be aware that simple TX path is in place and more
> > > restrictions should be
> > > met:
> > > check that nb_segs==1 and no TX offloads (except FAST_FREE?) are
> > > enabled, plus usual checks for min and max pkt_len.
> > >
> > > Konstantin
> > >
>
>
> Hi Leyi,
>
> > Hi Konstantin,
> >
> > Thanks for the explanation, I know the current full-featured prepare
> > function will cost more CPU cycle, but not sure how to say is still unsafe?
>
> Let say user will do:
>
> mb = create_and_fill_multi_seg_pkt(...);
> n = rte_eth_tx_prepare(p, q, &mb, 1);
> if (n == 1)
> n = rte_eth_tx_burst(p, q, &mb, 1);
> else
> rte_pktmbuf_free(mb);
>
> if dev->tx_pkt_prepare == i40e_prep_pkts and dev->tx_pkt_burs ==
> i40e_xmit_pkts_simple, then this code will TX the packet, even though it
> shouldn't in theory.
>
Hi Konstantin,
Yes, it make sense for the current situation.
> > Why I set the simple Tx prepare function to the current
> > i40e_prep_pkts() is we may support more offload features like current full-
> featured Tx for vector path(which is included in simple Tx currently), if so,
> the
> current tx prepare function can be re-used.
>
> AFAIK, for i40e current simple (and vector) TX path doesn't support all
> offloads
> that are supported by full-featured path To be more specific: mulit-seg
> packets,
> TCP_CKSUM, TCP_SEG, etc.
> Am I missing something obvious here?
>
> Konstantin
We're intending to support more offload features into vector path gradually,
ice/iavf PMD will support Tx checksum offload in AVX512 path in the 2105
release, also will try to support more in the future if possible.
Re: [dpdk-dev] [PATCH v4 0/4] Support PPS(packet per second) on meter
On 4/13/2021 4:50 AM, Li Zhang wrote:
Currently meter algorithms only supports rate is bytes per second(BPS).
Add packet_mode flag in meter profile parameters data structure.
So that it can meter traffic by packet per second.
When packet_mode is 0, the profile rates and bucket sizes are
specified in bytes per second and bytes
when packet_mode is not 0, the profile rates and bucket sizes are
specified in packets and packets per second.
Add the necessary checks to the existing drivers implementing
the rte_mtr API to makes sure that profiles with
packet_mode set to TRUE are rejected.
RFC ("adds support PPS(packet per second) on meter")
https://patchwork.dpdk.org/project/dpdk/patch/20210125012023.1769769-2-l...@nvidia.com/
Depends-on: series=16301 ("Support meter policy API ")
https://patchwork.dpdk.org/project/dpdk/list/?series=16301
Hi Li,
I am not clear with the dependency chain, can you please clarify,
1) Is this set depends to series-16301? Because it compiles fine after conflict
resolved, I can see in your repo there is an order, but if there is no
functional/logical dependency you can set this patch exactly on top of HEAD
(removing the series-16301 in between), so the CI will be enabled.
2) According its cover letter series-16301 depends on mlx ASO patch, this makes
all ethdev patches dependent to mlx5 set, I guess that is wrong, can you please
confirm?
Above (1) is more important, since series-16301 not fully acked, it is blocking
me to proceed.
V2: create a unified patch that contains both the series with
the API changes and the series with the necessary error checks in the
drivers.
V3: Fix comments about commit-log.
V4: Fix comments about Depends-on and rebase.
Li Zhang (4):
ethdev: add packet mode in meter profile structure
app/testpmd: add meter profile packet mode option
net/softnic: check meter packet mode
net/mvpp2: check meter packet mode
app/test-pmd/cmdline_mtr.c | 40 -
doc/guides/rel_notes/release_21_05.rst | 12 +++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 31 +++
drivers/net/mvpp2/mrvl_mtr.c| 6 ++
drivers/net/softnic/rte_eth_softnic_meter.c | 8 ++
lib/librte_ethdev/rte_mtr.h | 90 ++---
6 files changed, 159 insertions(+), 28 deletions(-)
[dpdk-dev] [PATCH v8 0/3] Enhancements to crypto adapter forward mode
This series proposes a new event device enqueue operation if crypto
adapter forward mode is supported. Second patch in the series is the
implementation of the same in PMD. Test application changes are added in
third patch.
v8:
- Added metadata NULL check and op free.
- events object - > event objects.
- Added Acked-by.
v7:
- Rebased.
v6:
- Rebased.
v5:
- Set rte_errno if crypto adapter enqueue fails in driver.
- Test application code restructuring.
v4:
- Fix debug build.
v3:
- Added crypto adapter test application changes.
v2:
- Updated release notes.
- Made use of RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET macro.
- Fixed v1 build error.
v1:
- Added crypto adapter forward mode support for octeontx2.
Akhil Goyal (1):
eventdev: introduce crypto adapter enqueue API
Shijith Thotton (2):
event/octeontx2: support crypto adapter forward mode
test/event_crypto: use crypto adapter enqueue API
app/test/test_event_crypto_adapter.c | 33 +---
.../prog_guide/event_crypto_adapter.rst | 69 +--
doc/guides/rel_notes/release_21_05.rst| 6 ++
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 49 +++
drivers/event/octeontx2/otx2_evdev.c | 5 +-
.../event/octeontx2/otx2_evdev_crypto_adptr.c | 3 +-
...dptr_dp.h => otx2_evdev_crypto_adptr_rx.h} | 6 +-
.../octeontx2/otx2_evdev_crypto_adptr_tx.h| 83 +++
drivers/event/octeontx2/otx2_worker.h | 2 +-
drivers/event/octeontx2/otx2_worker_dual.h| 2 +-
lib/librte_eventdev/eventdev_trace_points.c | 3 +
.../rte_event_crypto_adapter.h| 63 ++
lib/librte_eventdev/rte_eventdev.c| 10 +++
lib/librte_eventdev/rte_eventdev.h| 8 +-
lib/librte_eventdev/rte_eventdev_trace_fp.h | 10 +++
lib/librte_eventdev/version.map | 1 +
16 files changed, 293 insertions(+), 60 deletions(-)
rename drivers/event/octeontx2/{otx2_evdev_crypto_adptr_dp.h =>
otx2_evdev_crypto_adptr_rx.h} (93%)
create mode 100644 drivers/event/octeontx2/otx2_evdev_crypto_adptr_tx.h
--
2.25.1
[dpdk-dev] [PATCH v8 1/3] eventdev: introduce crypto adapter enqueue API
From: Akhil Goyal In case an event from a previous stage is required to be forwarded to a crypto adapter and PMD supports internal event port in crypto adapter, exposed via capability RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD, we do not have a way to check in the API rte_event_enqueue_burst(), whether it is for crypto adapter or for eth tx adapter. Hence we need a new API similar to rte_event_eth_tx_adapter_enqueue(), which can send to a crypto adapter. Note that RTE_EVENT_TYPE_* cannot be used to make that decision, as it is meant for event source and not event destination. And event port designated for crypto adapter is designed to be used for OP_NEW mode. Hence, in order to support an event PMD which has an internal event port in crypto adapter (RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode), exposed via capability RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD, application should use rte_event_crypto_adapter_enqueue() API to enqueue events. When internal port is not available(RTE_EVENT_CRYPTO_ADAPTER_OP_NEW mode), application can use API rte_event_enqueue_burst() as it was doing earlier, i.e. retrieve event port used by crypto adapter and bind its event queues to that port and enqueue events using the API rte_event_enqueue_burst(). Signed-off-by: Akhil Goyal Acked-by: Abhinandan Gujjar --- .../prog_guide/event_crypto_adapter.rst | 69 --- doc/guides/rel_notes/release_21_05.rst| 6 ++ lib/librte_eventdev/eventdev_trace_points.c | 3 + .../rte_event_crypto_adapter.h| 63 + lib/librte_eventdev/rte_eventdev.c| 10 +++ lib/librte_eventdev/rte_eventdev.h| 8 ++- lib/librte_eventdev/rte_eventdev_trace_fp.h | 10 +++ lib/librte_eventdev/version.map | 1 + 8 files changed, 143 insertions(+), 27 deletions(-) diff --git a/doc/guides/prog_guide/event_crypto_adapter.rst b/doc/guides/prog_guide/event_crypto_adapter.rst index 1e3eb7139..4fb5c688e 100644 --- a/doc/guides/prog_guide/event_crypto_adapter.rst +++ b/doc/guides/prog_guide/event_crypto_adapter.rst @@ -55,21 +55,22 @@ which is needed to enqueue an event after the crypto operation is completed. RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode -In the RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode, if HW supports -RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD capability the application -can directly submit the crypto operations to the cryptodev. -If not, application retrieves crypto adapter's event port using -rte_event_crypto_adapter_event_port_get() API. Then, links its event -queue to this port and starts enqueuing crypto operations as events -to the eventdev. The adapter then dequeues the events and submits the -crypto operations to the cryptodev. After the crypto completions, the -adapter enqueues events to the event device. -Application can use this mode, when ingress packet ordering is needed. -In this mode, events dequeued from the adapter will be treated as -forwarded events. The application needs to specify the cryptodev ID -and queue pair ID (request information) needed to enqueue a crypto -operation in addition to the event information (response information) -needed to enqueue an event after the crypto operation has completed. +In the ``RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD`` mode, if the event PMD and crypto +PMD supports internal event port +(``RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD``), the application should +use ``rte_event_crypto_adapter_enqueue()`` API to enqueue crypto operations as +events to crypto adapter. If not, application retrieves crypto adapter's event +port using ``rte_event_crypto_adapter_event_port_get()`` API, links its event +queue to this port and starts enqueuing crypto operations as events to eventdev +using ``rte_event_enqueue_burst()``. The adapter then dequeues the events and +submits the crypto operations to the cryptodev. After the crypto operation is +complete, the adapter enqueues events to the event device. The application can +use this mode when ingress packet ordering is needed. In this mode, events +dequeued from the adapter will be treated as forwarded events. The application +needs to specify the cryptodev ID and queue pair ID (request information) needed +to enqueue a crypto operation in addition to the event information (response +information) needed to enqueue an event after the crypto operation has +completed. .. _figure_event_crypto_adapter_op_forward: @@ -120,28 +121,44 @@ service function and needs to create an event port for it. The callback is expected to fill the ``struct rte_event_crypto_adapter_conf`` structure passed to it. -For RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode, the event port created by adapter -can be retrieved using ``rte_event_crypto_adapter_event_port_get()`` API. -Application can use this event port to link with event queue on which it -enqueues events towards the crypto adapter. +In the ``RTE_EVENT_CRYPTO
[dpdk-dev] [PATCH v8 3/3] test/event_crypto: use crypto adapter enqueue API
Use rte_event_crypto_adapter_enqueue() API to enqueue events to crypto
adapter if forward mode is supported in driver.
Signed-off-by: Shijith Thotton
Acked-by: Abhinandan Gujjar
---
app/test/test_event_crypto_adapter.c | 33 ++--
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/app/test/test_event_crypto_adapter.c
b/app/test/test_event_crypto_adapter.c
index 335211cd8..f689bc1f2 100644
--- a/app/test/test_event_crypto_adapter.c
+++ b/app/test/test_event_crypto_adapter.c
@@ -64,6 +64,7 @@ struct event_crypto_adapter_test_params {
struct rte_mempool *session_priv_mpool;
struct rte_cryptodev_config *config;
uint8_t crypto_event_port_id;
+ uint8_t internal_port_op_fwd;
};
struct rte_event response_info = {
@@ -110,9 +111,12 @@ send_recv_ev(struct rte_event *ev)
struct rte_event recv_ev;
int ret;
- ret = rte_event_enqueue_burst(evdev, TEST_APP_PORT_ID, ev, NUM);
- TEST_ASSERT_EQUAL(ret, NUM,
- "Failed to send event to crypto adapter\n");
+ if (params.internal_port_op_fwd)
+ ret = rte_event_crypto_adapter_enqueue(evdev, TEST_APP_PORT_ID,
+ ev, NUM);
+ else
+ ret = rte_event_enqueue_burst(evdev, TEST_APP_PORT_ID, ev, NUM);
+ TEST_ASSERT_EQUAL(ret, NUM, "Failed to send event to crypto adapter\n");
while (rte_event_dequeue_burst(evdev,
TEST_APP_PORT_ID, &recv_ev, NUM, 0) == 0)
@@ -747,9 +751,12 @@ configure_event_crypto_adapter(enum
rte_event_crypto_adapter_mode mode)
!(cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND))
goto adapter_create;
- if ((mode == RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD) &&
- !(cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD))
- return -ENOTSUP;
+ if (mode == RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD) {
+ if (cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD)
+ params.internal_port_op_fwd = 1;
+ else
+ return -ENOTSUP;
+ }
if ((mode == RTE_EVENT_CRYPTO_ADAPTER_OP_NEW) &&
!(cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW))
@@ -771,9 +778,11 @@ configure_event_crypto_adapter(enum
rte_event_crypto_adapter_mode mode)
TEST_ASSERT_SUCCESS(ret, "Failed to add queue pair\n");
- ret = rte_event_crypto_adapter_event_port_get(TEST_ADAPTER_ID,
- ¶ms.crypto_event_port_id);
- TEST_ASSERT_SUCCESS(ret, "Failed to get event port\n");
+ if (!params.internal_port_op_fwd) {
+ ret = rte_event_crypto_adapter_event_port_get(TEST_ADAPTER_ID,
+ ¶ms.crypto_event_port_id);
+ TEST_ASSERT_SUCCESS(ret, "Failed to get event port\n");
+ }
return TEST_SUCCESS;
}
@@ -809,15 +818,15 @@ test_crypto_adapter_conf(enum
rte_event_crypto_adapter_mode mode)
if (!crypto_adapter_setup_done) {
ret = configure_event_crypto_adapter(mode);
- if (!ret) {
+ if (ret)
+ return ret;
+ if (!params.internal_port_op_fwd) {
qid = TEST_CRYPTO_EV_QUEUE_ID;
ret = rte_event_port_link(evdev,
params.crypto_event_port_id, &qid, NULL, 1);
TEST_ASSERT(ret >= 0, "Failed to link queue %d "
"port=%u\n", qid,
params.crypto_event_port_id);
- } else {
- return ret;
}
crypto_adapter_setup_done = 1;
}
--
2.25.1
[dpdk-dev] [PATCH v8 2/3] event/octeontx2: support crypto adapter forward mode
Advertise crypto adapter forward mode capability and set crypto adapter
enqueue function in driver.
Signed-off-by: Shijith Thotton
Acked-by: Abhinandan Gujjar
---
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 49 +++
drivers/event/octeontx2/otx2_evdev.c | 5 +-
.../event/octeontx2/otx2_evdev_crypto_adptr.c | 3 +-
...dptr_dp.h => otx2_evdev_crypto_adptr_rx.h} | 6 +-
.../octeontx2/otx2_evdev_crypto_adptr_tx.h| 83 +++
drivers/event/octeontx2/otx2_worker.h | 2 +-
drivers/event/octeontx2/otx2_worker_dual.h| 2 +-
7 files changed, 129 insertions(+), 21 deletions(-)
rename drivers/event/octeontx2/{otx2_evdev_crypto_adptr_dp.h =>
otx2_evdev_crypto_adptr_rx.h} (93%)
create mode 100644 drivers/event/octeontx2/otx2_evdev_crypto_adptr_tx.h
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
index cec20b5c6..c918ed864 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include "otx2_cryptodev.h"
#include "otx2_cryptodev_capabilities.h"
@@ -434,15 +435,35 @@ sym_session_configure(int driver_id, struct
rte_crypto_sym_xform *xform,
return -ENOTSUP;
}
-static __rte_always_inline void __rte_hot
+static __rte_always_inline int32_t __rte_hot
otx2_ca_enqueue_req(const struct otx2_cpt_qp *qp,
struct cpt_request_info *req,
void *lmtline,
+ struct rte_crypto_op *op,
uint64_t cpt_inst_w7)
{
+ union rte_event_crypto_metadata *m_data;
union cpt_inst_s inst;
uint64_t lmt_status;
+ if (op->sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
+ m_data = rte_cryptodev_sym_session_get_user_data(
+ op->sym->session);
+ if (m_data == NULL) {
+ rte_pktmbuf_free(op->sym->m_src);
+ rte_crypto_op_free(op);
+ rte_errno = EINVAL;
+ return -EINVAL;
+ }
+ } else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
+ op->private_data_offset) {
+ m_data = (union rte_event_crypto_metadata *)
+((uint8_t *)op +
+ op->private_data_offset);
+ } else {
+ return -EINVAL;
+ }
+
inst.u[0] = 0;
inst.s9x.res_addr = req->comp_baddr;
inst.u[2] = 0;
@@ -453,12 +474,11 @@ otx2_ca_enqueue_req(const struct otx2_cpt_qp *qp,
inst.s9x.ei2 = req->ist.ei2;
inst.s9x.ei3 = cpt_inst_w7;
- inst.s9x.qord = 1;
- inst.s9x.grp = qp->ev.queue_id;
- inst.s9x.tt = qp->ev.sched_type;
- inst.s9x.tag = (RTE_EVENT_TYPE_CRYPTODEV << 28) |
- qp->ev.flow_id;
- inst.s9x.wq_ptr = (uint64_t)req >> 3;
+ inst.u[2] = (((RTE_EVENT_TYPE_CRYPTODEV << 28) |
+ m_data->response_info.flow_id) |
+((uint64_t)m_data->response_info.sched_type << 32) |
+((uint64_t)m_data->response_info.queue_id << 34));
+ inst.u[3] = 1 | (((uint64_t)req >> 3) << 3);
req->qp = qp;
do {
@@ -475,22 +495,22 @@ otx2_ca_enqueue_req(const struct otx2_cpt_qp *qp,
lmt_status = otx2_lmt_submit(qp->lf_nq_reg);
} while (lmt_status == 0);
+ return 0;
}
static __rte_always_inline int32_t __rte_hot
otx2_cpt_enqueue_req(const struct otx2_cpt_qp *qp,
struct pending_queue *pend_q,
struct cpt_request_info *req,
+struct rte_crypto_op *op,
uint64_t cpt_inst_w7)
{
void *lmtline = qp->lmtline;
union cpt_inst_s inst;
uint64_t lmt_status;
- if (qp->ca_enable) {
- otx2_ca_enqueue_req(qp, req, lmtline, cpt_inst_w7);
- return 0;
- }
+ if (qp->ca_enable)
+ return otx2_ca_enqueue_req(qp, req, lmtline, op, cpt_inst_w7);
if (unlikely(pend_q->pending_count >= OTX2_CPT_DEFAULT_CMD_QLEN))
return -EAGAIN;
@@ -594,7 +614,8 @@ otx2_cpt_enqueue_asym(struct otx2_cpt_qp *qp,
goto req_fail;
}
- ret = otx2_cpt_enqueue_req(qp, pend_q, params.req, sess->cpt_inst_w7);
+ ret = otx2_cpt_enqueue_req(qp, pend_q, params.req, op,
+ sess->cpt_inst_w7);
if (unlikely(ret)) {
CPT_LOG_DP_ERR("Could not enqueue crypto req");
@@ -638,7 +659,7 @@ otx2_cpt_enqueue_sym(struct otx2_cpt_qp *qp, struct
rte_crypto_op *op,
return ret;
}
- ret = otx2_cpt_enqueue_req(qp, pend_q, req, sess->cpt_inst_w7);
+ ret = otx2_cpt_enqueue_req(qp, pend_q, req, op, sess->cpt_inst_w7);
if (unlikely(ret)) {
Re: [dpdk-dev] [PATCH] drivers: add missing headers
On 3/26/21 7:46 PM, Ferruh Yigit wrote: > These headers are used but not included explicitly, including them. > > "arpa/inet.h" is included for 'htons' and friends. > "netinet/in.h" is included for 'IPPROTO_IP'. > > Signed-off-by: Ferruh Yigit Acked-by: Andrew Rybchenko
Re: [dpdk-dev] [PATCH v1] net/enic: fix completion pointer calculation
On 4/12/2021 9:50 PM, John Daley wrote:
The completion queue index could be implicitly extended past its
uint16_t size when multiplied by the size of the descriptor. While
this should not be a problem, coverity flags it. Do the extension
explicitly by casting the index to uintptr_t.
Coverity issue: 161317
Fixes: 8b428cb5a92e ("net/enic: use 64B completion queue entries if available")
Cc: sta...@dpdk.org
Signed-off-by: John Daley
Reviewed-by: Hyong Youb Kim
Applied to dpdk-next-net/main, thanks.
Re: [dpdk-dev] [PATCH] net/i40e: add Tx preparation for vector data path
> >
> > > > > > > Fill up dev->tx_pkt_prepare to i40e_pkt_prepare when on vector
> > > > > > > and simple data path selection, as the sanity check is needed
> > > > > > > ideally.
> > > > > > >
> > > > > > > Signed-off-by: Leyi Rong
> > > > > > > ---
> > > > > > > drivers/net/i40e/i40e_rxtx.c | 2 +-
> > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/drivers/net/i40e/i40e_rxtx.c
> > > > > > > b/drivers/net/i40e/i40e_rxtx.c index 61cb204be2..b3d7765e3b
> > > > > > > 100644
> > > > > > > --- a/drivers/net/i40e/i40e_rxtx.c
> > > > > > > +++ b/drivers/net/i40e/i40e_rxtx.c
> > > > > > > @@ -3412,7 +3412,7 @@ i40e_set_tx_function(struct rte_eth_dev
> > *dev)
> > > > > > > PMD_INIT_LOG(DEBUG, "Simple tx finally
> > > > > > > be
> > used.");
> > > > > > > dev->tx_pkt_burst =
> > > > > > > i40e_xmit_pkts_simple;
> > > > > > > }
> > > > > > > - dev->tx_pkt_prepare = NULL;
> > > > > > > + dev->tx_pkt_prepare = i40e_prep_pkts;
> > > > > > > } else {
> > > > > > > PMD_INIT_LOG(DEBUG, "Xmit tx finally be used.");
> > > > > > > dev->tx_pkt_burst = i40e_xmit_pkts;
> > > > > > >
> > > > > >
> > > > > > It seems prepare function is doing some sanity checks before
> > > > > > handing packets to the HW.
> > > > > > So with this change all Tx paths calls the same Tx prepare
> > > > > > function, if so why not set the function pointer outside of the
> > > > > > if block, instead of setting it in both legs of the if/else?
> > > > > > This clarifies that Tx prepare
> > > > used always.
> > > > >
> > > > > Hi Ferruh,
> > > > >
> > > > > Yes, it make sense.
> > > > >
> > > > > Hi Konstantin,
> > > >
> > > > Hi Leyi,
> > > >
> > > > >
> > > > > Would that be something wrong if the prepare function goes for
> > > > > simple Tx
> > > > function although it does not support the offload feature yet?
> > > > >
> > > >
> > > > Current situation:
> > > > For simple TX path we set dev->tx_pkt_prepare = NULL.
> > > > That makes rte_eth_tx_prepare() a stub that does nothing and always
> > returns:
> > > > "All packets are good".
> > > > That is unsafe off-course, and if upper layer will pass a packet
> > > > that is not supported, then it can lead to various bad things: bad
> > > > cksum, corrupted packets, TX hang, etc.
> > > > But at least it keeps simple TX path fast.
> > > > With that patch:
> > > > For simple TX path we set dev->tx_pkt_prepare = i40e_prep_pkts.
> > > > Now on TX path we invoke extra function that does a lot of checks,
> > > > but it still
> > > > unsafe:
> > > > as i40e_prep_pkts() assumes that full-featured TX function is in
> > > > place (multi-segs are allowed, etc.).
> > > > So our simple TX path became slower, but still is unsafe.
> > > > I think that if we want to introduce tx_prepare() for simple TX
> > > > path, then the proper way - create a new function for it
> > (i40e_simple_prep_pkts() or so).
> > > > It will be aware that simple TX path is in place and more
> > > > restrictions should be
> > > > met:
> > > > check that nb_segs==1 and no TX offloads (except FAST_FREE?) are
> > > > enabled, plus usual checks for min and max pkt_len.
> > > >
> > > > Konstantin
> > > >
> >
> >
> > Hi Leyi,
> >
> > > Hi Konstantin,
> > >
> > > Thanks for the explanation, I know the current full-featured prepare
> > > function will cost more CPU cycle, but not sure how to say is still
> > > unsafe?
> >
> > Let say user will do:
> >
> > mb = create_and_fill_multi_seg_pkt(...);
> > n = rte_eth_tx_prepare(p, q, &mb, 1);
> > if (n == 1)
> > n = rte_eth_tx_burst(p, q, &mb, 1);
> > else
> > rte_pktmbuf_free(mb);
> >
> > if dev->tx_pkt_prepare == i40e_prep_pkts and dev->tx_pkt_burs ==
> > i40e_xmit_pkts_simple, then this code will TX the packet, even though it
> > shouldn't in theory.
> >
>
> Hi Konstantin,
>
> Yes, it make sense for the current situation.
Hmm, could you elaborate a bit: what exactly makes sense?
>
> > > Why I set the simple Tx prepare function to the current
> > > i40e_prep_pkts() is we may support more offload features like current
> > > full-
> > featured Tx for vector path(which is included in simple Tx currently), if
> > so, the
> > current tx prepare function can be re-used.
> >
> > AFAIK, for i40e current simple (and vector) TX path doesn't support all
> > offloads
> > that are supported by full-featured path To be more specific: mulit-seg
> > packets,
> > TCP_CKSUM, TCP_SEG, etc.
> > Am I missing something obvious here?
> >
> > Konstantin
>
> We're intending to support more offload features into vector path gradually,
> ice/iavf PMD will support Tx checksum offload in AVX512 path
> in the 2105 release, also will try to support more in the future if possible.
Well, when i40e vector TX will support these offloads, then it will make sense
to
use the same prepare function for it.
But right now, I think it is
Re: [dpdk-dev] [dpdk-stable] [PATCH] license: fix typo
> >> Fixes: a4862c9e1a98 ("license: introduce SPDX identifiers")
> >> Cc: sta...@dpdk.org
> >>
> >> Signed-off-by: Ferruh Yigit
> > Acked-by: Stephen Hemminger
> Acked-by: Hemant Agrawal
Applied, thanks
Re: [dpdk-dev] [PATCH v4 0/4] Support PPS(packet per second) on meter
Hi Ferruh,
> -Original Message-
> From: Ferruh Yigit
> Sent: Tuesday, April 13, 2021 6:25 PM
> To: Li Zhang ; dek...@nvidia.com; Ori Kam
> ; Slava Ovsiienko ; Matan
> Azrad ; Shahaf Shuler ;
> cristian.dumitre...@intel.com; lir...@marvell.com; jer...@marvell.com
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon ;
> Raslan Darawsheh ; Roni Bar Yanai
>
> Subject: Re: [PATCH v4 0/4] Support PPS(packet per second) on meter
>
> External email: Use caution opening links or attachments
>
>
> On 4/13/2021 4:50 AM, Li Zhang wrote:
> > Currently meter algorithms only supports rate is bytes per second(BPS).
> > Add packet_mode flag in meter profile parameters data structure.
> > So that it can meter traffic by packet per second.
> >
> > When packet_mode is 0, the profile rates and bucket sizes are
> > specified in bytes per second and bytes when packet_mode is not 0, the
> > profile rates and bucket sizes are specified in packets and packets
> > per second.
> >
> > Add the necessary checks to the existing drivers implementing the
> > rte_mtr API to makes sure that profiles with packet_mode set to TRUE
> > are rejected.
> >
> > RFC ("adds support PPS(packet per second) on meter")
> > https://patchwork.dpdk.org/project/dpdk/patch/20210125012023.1769769-
> 2
> > -l...@nvidia.com/
> >
> > Depends-on: series=16301 ("Support meter policy API ")
> > https://patchwork.dpdk.org/project/dpdk/list/?series=16301
> >
>
> Hi Li,
>
> I am not clear with the dependency chain, can you please clarify,
>
> 1) Is this set depends to series-16301? Because it compiles fine after
> conflict
> resolved, I can see in your repo there is an order, but if there is no
> functional/logical dependency you can set this patch exactly on top of HEAD
> (removing the series-16301 in between), so the CI will be enabled.
I will delete series-16301.
But it will merge conflict when series-16301 merged after it.
> 2) According its cover letter series-16301 depends on mlx ASO patch, this
> makes all ethdev patches dependent to mlx5 set, I guess that is wrong, can you
> please confirm?
>
> Above (1) is more important, since series-16301 not fully acked, it is
> blocking
> me to proceed.
>
> > V2: create a unified patch that contains both the series with
> > the API changes and the series with the necessary error checks in the
> drivers.
> > V3: Fix comments about commit-log.
> > V4: Fix comments about Depends-on and rebase.
> >
> > Li Zhang (4):
> >ethdev: add packet mode in meter profile structure
> >app/testpmd: add meter profile packet mode option
> >net/softnic: check meter packet mode
> >net/mvpp2: check meter packet mode
> >
> > app/test-pmd/cmdline_mtr.c | 40 -
> > doc/guides/rel_notes/release_21_05.rst | 12 +++
> > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 31 +++
> > drivers/net/mvpp2/mrvl_mtr.c| 6 ++
> > drivers/net/softnic/rte_eth_softnic_meter.c | 8 ++
> > lib/librte_ethdev/rte_mtr.h | 90 ++---
> > 6 files changed, 159 insertions(+), 28 deletions(-)
> >
Re: [dpdk-dev] [PATCH v4 0/4] Support PPS(packet per second) on meter
On 4/13/2021 12:02 PM, Li Zhang wrote:
Hi Ferruh,
-Original Message-
From: Ferruh Yigit
Sent: Tuesday, April 13, 2021 6:25 PM
To: Li Zhang ; dek...@nvidia.com; Ori Kam
; Slava Ovsiienko ; Matan
Azrad ; Shahaf Shuler ;
cristian.dumitre...@intel.com; lir...@marvell.com; jer...@marvell.com
Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon ;
Raslan Darawsheh ; Roni Bar Yanai
Subject: Re: [PATCH v4 0/4] Support PPS(packet per second) on meter
External email: Use caution opening links or attachments
On 4/13/2021 4:50 AM, Li Zhang wrote:
Currently meter algorithms only supports rate is bytes per second(BPS).
Add packet_mode flag in meter profile parameters data structure.
So that it can meter traffic by packet per second.
When packet_mode is 0, the profile rates and bucket sizes are
specified in bytes per second and bytes when packet_mode is not 0, the
profile rates and bucket sizes are specified in packets and packets
per second.
Add the necessary checks to the existing drivers implementing the
rte_mtr API to makes sure that profiles with packet_mode set to TRUE
are rejected.
RFC ("adds support PPS(packet per second) on meter")
https://patchwork.dpdk.org/project/dpdk/patch/20210125012023.1769769-
2
-l...@nvidia.com/
Depends-on: series=16301 ("Support meter policy API ")
https://patchwork.dpdk.org/project/dpdk/list/?series=16301
Hi Li,
I am not clear with the dependency chain, can you please clarify,
1) Is this set depends to series-16301? Because it compiles fine after conflict
resolved, I can see in your repo there is an order, but if there is no
functional/logical dependency you can set this patch exactly on top of HEAD
(removing the series-16301 in between), so the CI will be enabled.
I will delete series-16301.
But it will merge conflict when series-16301 merged after it.
Please send both this patch, and series-16301 on top of latest head, this
enables CI for both.
When merging them we can handle the conflict, based on which one merged first,
or can ask you to rebase the second one but for this case it does not look too
complex to resolve ourselves.
2) According its cover letter series-16301 depends on mlx ASO patch, this
makes all ethdev patches dependent to mlx5 set, I guess that is wrong, can you
please confirm?
Above (1) is more important, since series-16301 not fully acked, it is blocking
me to proceed.
V2: create a unified patch that contains both the series with
the API changes and the series with the necessary error checks in the
drivers.
V3: Fix comments about commit-log.
V4: Fix comments about Depends-on and rebase.
Li Zhang (4):
ethdev: add packet mode in meter profile structure
app/testpmd: add meter profile packet mode option
net/softnic: check meter packet mode
net/mvpp2: check meter packet mode
app/test-pmd/cmdline_mtr.c | 40 -
doc/guides/rel_notes/release_21_05.rst | 12 +++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 31 +++
drivers/net/mvpp2/mrvl_mtr.c| 6 ++
drivers/net/softnic/rte_eth_softnic_meter.c | 8 ++
lib/librte_ethdev/rte_mtr.h | 90 ++---
6 files changed, 159 insertions(+), 28 deletions(-)
Re: [dpdk-dev] [PATCH v2 1/4] vhost: fix uninitialized vhost queue
On 4/2/21 3:03 PM, Jiayu Hu wrote:
> This patch allocates vhost queue by rte_zmalloc() to avoid
> undefined values.
>
> Fixes: a277c7159876 ("vhost: refactor code structure")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jiayu Hu
> ---
> lib/librte_vhost/vhost.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
> index c9d1371..8657bbe 100644
> --- a/lib/librte_vhost/vhost.c
> +++ b/lib/librte_vhost/vhost.c
> @@ -609,7 +609,7 @@ alloc_vring_queue(struct virtio_net *dev, uint32_t
> vring_idx)
> if (dev->virtqueue[i])
> continue;
>
> - vq = rte_malloc(NULL, sizeof(struct vhost_virtqueue), 0);
> + vq = rte_zmalloc(NULL, sizeof(struct vhost_virtqueue), 0);
> if (vq == NULL) {
> VHOST_LOG_CONFIG(ERR,
> "Failed to allocate memory for vring:%u.\n", i);
>
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v2 3/4] vhost: avoid deadlock on async register
On 4/2/21 3:04 PM, Jiayu Hu wrote:
> Users can register async copy device in vring_state_changed(),
> when vhost queue is enabled. However, a deadlock occurs inside
> rte_vhost_async_channel_register(), if VHOST_USER_F_PROTOCOL_FEATURES
> is not supported, as vhost_user_msg_handler() takes vq->access_lock
> before calling vhost_user_set_vring_kick().
>
> This patch avoids async register deadlock by removing calling
> vring_state_changed() in vhost_user_set_vring_kick(). It's safe
> as vhost_user_msg_handler() will call vring_state_changed() anyway.
>
> Signed-off-by: Jiayu Hu
> ---
> lib/librte_vhost/vhost_user.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> index 44c0452..8f0eba6 100644
> --- a/lib/librte_vhost/vhost_user.c
> +++ b/lib/librte_vhost/vhost_user.c
> @@ -1918,9 +1918,6 @@ vhost_user_set_vring_kick(struct virtio_net **pdev,
> struct VhostUserMsg *msg,
>*/
> if (!(dev->features & (1ULL << VHOST_USER_F_PROTOCOL_FEATURES))) {
> vq->enabled = true;
> - if (dev->notify_ops->vring_state_changed)
> - dev->notify_ops->vring_state_changed(
> - dev->vid, file.index, 1);
> }
>
> if (vq->ready) {
>
As replied earlier on v1, I agree the call to vring_state_changed here
is not needed. But it might not be enough, there are other cases where
you could have issues.
Please add stable and Fixes tag.
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v2 2/2] app/testpmd: add support for integrity item
Hi
> -Original Message-
> From: Ferruh Yigit
> item
>
> On 4/13/2021 8:53 AM, Ori Kam wrote:
> > Hi Ferruh,
> >
> >> -Original Message-
> >> From: Ferruh Yigit
> >>
> >> On 4/11/2021 6:34 PM, Gregory Etelson wrote:
> >>> From: Ori Kam
> >>>
> >>> The integrity item allows the application to match
> >>> on the integrity of a packet.
> >>>
> >>> use example:
> >>> match that packet integrity checks are ok. The checks depend on
> >>> packet layers. For example ICMP packet will not check L4 level.
> >>> flow create 0 ingress pattern integrity value mask 0x01 value spec 0x01
> >>> match that L4 packet is ok - check L2 & L3 & L4 layers:
> >>> flow create 0 ingress pattern integrity value mask 0xfe value spec 0xfe
> >>>
> >>> Signed-off-by: Ori Kam
> >>> Signed-off-by: Gregory Etelson
> >>> ---
> >>> v2 add testpmd patch
> >>> ---
> >>>app/test-pmd/cmdline_flow.c | 39
> >> +
> >>
> >> Hi Gregory, Ori,
> >>
> >> Can you add some samples to "testpmd_funcs.rst#flow-rules-management"?
> >>
> >> I asked in some other thread but did not get any response, what do you
> >> think
> to
> >> make 'testpmd_funcs.rst' sample update mandatory when testpmd flow
> added?
> >>
> > I fully agree that each new function should be mandatory,
>
> What is new function here, new flow API? That should go to flow API
> documentation, 'rte_flow.rst'.
>
I mean something like for example new set,
create_shared_action..
I mean new total new commands.
Does it make sense?
> > The question is do we want that each new item / action (they use existing
> function)
> > I think it is a bit of overhead but I don't have strong opinion.
> >
>
> Since the documentation is for the testpmd usage sample, I was thinking to add
> sample for each new item & action indeed.
> Same of the flow rules not widely used, and it is not always clear how to use
> them, that is why I believe documenting samples can help.
>
I fully agree with you, the question is how to do it,
since in some cases it is jut one line of code,
and in other cases it can be much more complex for example raw_encap,
the new Conntrack action.
I think we should think how we improve the examples in the rte_flow context,
> >>
> >>>1 file changed, 39 insertions(+)
> >>>
> >>> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> >>> index fb7a3a8bd3..b5dec34325 100644
> >>> --- a/app/test-pmd/cmdline_flow.c
> >>> +++ b/app/test-pmd/cmdline_flow.c
> >>> @@ -289,6 +289,9 @@ enum index {
> >>> ITEM_GENEVE_OPT_TYPE,
> >>> ITEM_GENEVE_OPT_LENGTH,
> >>> ITEM_GENEVE_OPT_DATA,
> >>> + ITEM_INTEGRITY,
> >>> + ITEM_INTEGRITY_LEVEL,
> >>> + ITEM_INTEGRITY_VALUE,
> >>>
> >>> /* Validate/create actions. */
> >>> ACTIONS,
> >>> @@ -956,6 +959,7 @@ static const enum index next_item[] = {
> >>> ITEM_PFCP,
> >>> ITEM_ECPRI,
> >>> ITEM_GENEVE_OPT,
> >>> + ITEM_INTEGRITY,
> >>> END_SET,
> >>> ZERO,
> >>>};
> >>> @@ -1307,6 +1311,19 @@ static const enum index item_geneve_opt[] = {
> >>> ZERO,
> >>>};
> >>>
> >>> +static const enum index item_integrity[] = {
> >>> + ITEM_INTEGRITY_LEVEL,
> >>> + ITEM_INTEGRITY_VALUE,
> >>> + ZERO,
> >>> +};
> >>> +
> >>> +static const enum index item_integrity_lv[] = {
> >>> + ITEM_INTEGRITY_LEVEL,
> >>> + ITEM_INTEGRITY_VALUE,
> >>> + ITEM_NEXT,
> >>> + ZERO,
> >>> +};
> >>> +
> >>>static const enum index next_action[] = {
> >>> ACTION_END,
> >>> ACTION_VOID,
> >>> @@ -3373,6 +3390,28 @@ static const struct token token_list[] = {
> >>> (sizeof(struct
> >>> rte_flow_item_geneve_opt),
> >>> ITEM_GENEVE_OPT_DATA_SIZE)),
> >>> },
> >>> + [ITEM_INTEGRITY] = {
> >>> + .name = "integrity",
> >>> + .help = "match packet integrity",
> >>> + .priv = PRIV_ITEM(INTEGRITY,
> >>> + sizeof(struct rte_flow_item_integrity)),
> >>> + .next = NEXT(item_integrity),
> >>> + .call = parse_vc,
> >>> + },
> >>> + [ITEM_INTEGRITY_LEVEL] = {
> >>> + .name = "level",
> >>> + .help = "integrity level",
> >>> + .next = NEXT(item_integrity_lv, NEXT_ENTRY(UNSIGNED),
> >>> + item_param),
> >>> + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_integrity,
> >> level)),
> >>> + },
> >>> + [ITEM_INTEGRITY_VALUE] = {
> >>> + .name = "value",
> >>> + .help = "integrity value",
> >>> + .next = NEXT(item_integrity_lv, NEXT_ENTRY(UNSIGNED),
> >>> + item_param),
> >>> + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_integrity,
> >> value)),
> >>> + },
> >>> /* Validate/create actions. */
> >>> [ACTIONS] = {
> >>> .name = "actions",
> >>>
> >
Re: [dpdk-dev] [PATCH] vhost: don't track remaining packets separately
Hi Balazs,
Your patch does not apply, it needs to be rebased:
http://patches.dpdk.org/project/dpdk/patch/5ef3d4c29927ed241c7128819fe35ac1d95d8f24.1617892982.git.bnem...@redhat.com/
Can you please send a rebased version.
Thanks,
Maxime
On 4/8/21 4:44 PM, Balazs Nemeth wrote:
> The remained variable stores the same information as the difference
> between count and pkt_idx. Remove the remained variable to simplify.
>
> Signed-off-by: Balazs Nemeth
> ---
> lib/librte_vhost/virtio_net.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
> index e8cc5f659..cfd52360d 100644
> --- a/lib/librte_vhost/virtio_net.c
> +++ b/lib/librte_vhost/virtio_net.c
> @@ -1353,16 +1353,14 @@ virtio_dev_rx_packed(struct virtio_net *dev,
>uint32_t count)
> {
> uint32_t pkt_idx = 0;
> - uint32_t remained = count;
>
> do {
> rte_prefetch0(&vq->desc_packed[vq->last_avail_idx]);
>
> - if (remained >= PACKED_BATCH_SIZE) {
> + if (count - pkt_idx >= PACKED_BATCH_SIZE) {
> if (!virtio_dev_rx_batch_packed(dev, vq,
> &pkts[pkt_idx])) {
> pkt_idx += PACKED_BATCH_SIZE;
> - remained -= PACKED_BATCH_SIZE;
> continue;
> }
> }
> @@ -1370,7 +1368,6 @@ virtio_dev_rx_packed(struct virtio_net *dev,
> if (virtio_dev_rx_single_packed(dev, vq, pkts[pkt_idx]))
> break;
> pkt_idx++;
> - remained--;
>
> } while (pkt_idx < count);
>
> @@ -2480,12 +2477,11 @@ virtio_dev_tx_packed(struct virtio_net *dev,
> do {
> rte_prefetch0(&vq->desc_packed[vq->last_avail_idx]);
>
> - if (remained >= PACKED_BATCH_SIZE) {
> + if (count - pkt_idx >= PACKED_BATCH_SIZE) {
>
> if (!virtio_dev_tx_batch_packed(dev, vq,
> &pkts[pkt_idx])) {
> pkt_idx += PACKED_BATCH_SIZE;
> - remained -= PACKED_BATCH_SIZE;
>
> continue;
> }
> @@ -2496,9 +2492,7 @@ virtio_dev_tx_packed(struct virtio_net *dev,
> break;
> }
> pkt_idx++;
> - remained--;
> -
> - } while (remained);
> + } while (pkt_idx < count);
>
> if (pkt_idx != count) {
> rte_pktmbuf_free_bulk(&pkts[pkt_idx], count - pkt_idx);
>
Re: [dpdk-dev] [PATCH v2 00/14] base code update batch 2
On 4/13/2021 7:16 AM, Yang, Qiming wrote: -Original Message- From: Zhang, Qi Z Sent: 2021年4月13日 13:06 To: Yang, Qiming Cc: dev@dpdk.org; Zhang, Qi Z Subject: [PATCH v2 00/14] base code update batch 2 v2: - Added patch 9/14 - 14/14. Qi Zhang (14): net/ice/base: code cleanup net/ice/base: support removing VSI from flow profile net/ice/base: print link configure error net/ice/base: remove unused ptype field in PTT definition net/ice/base: set MAC type for E823C device net/ice/base: change protocol ID for VLAN in case of DVM net/ice/base: enable I2C read/write commands net/ice/base: add RSS support for PPPoL2TPv2oUDP net/ice/base: add set/get GPIO helper functions net/ice/base: add priority check of matching recipe net/ice/base: add inner VLAN protocol type for QinQ filter net/ice/base: fix QinQ PPPoE dummy pkt selection net/ice/base: add PTYPE values for PPPoL2TPv2oUDP net/ice/base: allow support for GTP-U filter using only inner protocols drivers/net/ice/base/ice_adminq_cmd.h| 40 ++ drivers/net/ice/base/ice_common.c| 162 ++- drivers/net/ice/base/ice_common.h| 14 ++ drivers/net/ice/base/ice_dcb.c | 2 +- drivers/net/ice/base/ice_fdir.c | 2 +- drivers/net/ice/base/ice_flex_pipe.c | 4 +- drivers/net/ice/base/ice_flex_type.h | 31 - drivers/net/ice/base/ice_flow.c | 120 ++--- drivers/net/ice/base/ice_flow.h | 4 + drivers/net/ice/base/ice_lan_tx_rx.h | 10 +- drivers/net/ice/base/ice_protocol_type.h | 4 + drivers/net/ice/base/ice_sched.c | 11 +- drivers/net/ice/base/ice_switch.c| 77 +++ drivers/net/ice/base/ice_switch.h| 1 + drivers/net/ice/base/ice_type.h | 2 - drivers/net/ice/base/ice_vlan_mode.c | 3 +- drivers/net/ice/base/ice_vlan_mode.h | 1 - 17 files changed, 424 insertions(+), 64 deletions(-) -- 2.26.2 Acked-by: Qiming Yang Hi Qiming, Qi, The set fails to build, please check reports on patchwork: https://patches.dpdk.org/project/dpdk/patch/20210413050640.2586033-15-qi.z.zh...@intel.com/
Re: [dpdk-dev] [PATCH] net/hns3: support trace Rx/Tx burst function
在 2021/4/13 17:13, Ferruh Yigit 写道: On 4/13/2021 10:03 AM, David Marchand wrote: On Tue, Apr 13, 2021 at 10:37 AM Ferruh Yigit wrote: On 4/9/2021 11:26 AM, Min Hu (Connor) wrote: From: Chengwen Feng This patch adds debug info for Rx/Tx burst function which was choosing. Signed-off-by: Chengwen Feng Signed-off-by: Min Hu (Connor) Applied to dpdk-next-net/main, thanks. Can we avoid mentioning "trace" in the title? This is to avoid confusion with rte_trace. Indeed, I also though if it is adding rte_trace support when I first see the title, I will update it to: "net/hns3: log selected datapath" OK, thanks Ferruh and David. .
Re: [dpdk-dev] [PATCH v3] vhost: read last used index once
On 4/7/21 11:55 AM, Balazs Nemeth wrote:
> Instead of calculating the address of a packed descriptor based on the
> vq->desc_packed and vq->last_used_idx every time, store that base
> address in desc_base. On arm, this saves 176 bytes in code size of
> function in which vhost_flush_enqueue_batch_packed gets inlined.
>
> Signed-off-by: Balazs Nemeth
> ---
> lib/librte_vhost/virtio_net.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
> index 179c57b46..f091384a6 100644
> --- a/lib/librte_vhost/virtio_net.c
> +++ b/lib/librte_vhost/virtio_net.c
> @@ -217,6 +217,8 @@ vhost_flush_enqueue_batch_packed(struct virtio_net *dev,
> {
> uint16_t i;
> uint16_t flags;
> + uint16_t last_used_idx = vq->last_used_idx;
> + struct vring_packed_desc *desc_base = &vq->desc_packed[last_used_idx];
>
> if (vq->shadow_used_idx) {
> do_data_copy_enqueue(dev, vq);
> @@ -226,16 +228,17 @@ vhost_flush_enqueue_batch_packed(struct virtio_net *dev,
> flags = PACKED_DESC_ENQUEUE_USED_FLAG(vq->used_wrap_counter);
>
> vhost_for_each_try_unroll(i, 0, PACKED_BATCH_SIZE) {
> - vq->desc_packed[vq->last_used_idx + i].id = ids[i];
> - vq->desc_packed[vq->last_used_idx + i].len = lens[i];
> + desc_base[i].id = ids[i];
> + desc_base[i].len = lens[i];
> }
>
> rte_atomic_thread_fence(__ATOMIC_RELEASE);
>
> - vhost_for_each_try_unroll(i, 0, PACKED_BATCH_SIZE)
> - vq->desc_packed[vq->last_used_idx + i].flags = flags;
> + vhost_for_each_try_unroll(i, 0, PACKED_BATCH_SIZE) {
> + desc_base[i].flags = flags;
> + }
>
> - vhost_log_cache_used_vring(dev, vq, vq->last_used_idx *
> + vhost_log_cache_used_vring(dev, vq, last_used_idx *
> sizeof(struct vring_packed_desc),
> sizeof(struct vring_packed_desc) *
> PACKED_BATCH_SIZE);
>
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v5 2/4] vhost: add support for packed ring in async vhost
Hi Maxime,
> -Original Message-
> From: Maxime Coquelin
> Sent: Tuesday, April 13, 2021 4:37 PM
> To: Jiang, Cheng1 ; Xia, Chenbo
>
> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> ; Wang, Yinan ; Liu,
> Yong
> Subject: Re: [PATCH v5 2/4] vhost: add support for packed ring in async vhost
>
>
>
> On 4/12/21 1:34 PM, Cheng Jiang wrote:
> > For now async vhost data path only supports split ring structure. In
> > order to make async vhost compatible with virtio 1.1 spec this patch
> > enables packed ring in async vhost data path.
> >
> > Signed-off-by: Cheng Jiang
> > ---
> > lib/librte_vhost/rte_vhost_async.h | 1 +
> > lib/librte_vhost/vhost.c | 27 +-
> > lib/librte_vhost/vhost.h | 7 +-
> > lib/librte_vhost/virtio_net.c | 438 +++--
> > 4 files changed, 448 insertions(+), 25 deletions(-)
> >
> > diff --git a/lib/librte_vhost/rte_vhost_async.h
> > b/lib/librte_vhost/rte_vhost_async.h
> > index c855ff875..6faa31f5a 100644
> > --- a/lib/librte_vhost/rte_vhost_async.h
> > +++ b/lib/librte_vhost/rte_vhost_async.h
> > @@ -89,6 +89,7 @@ struct rte_vhost_async_channel_ops { struct
> > async_inflight_info {
> > struct rte_mbuf *mbuf;
> > uint16_t descs; /* num of descs inflight */
> > + uint16_t nr_buffers; /* num of buffers inflight for packed ring */
> > };
> >
> > /**
> > diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c index
> > a70fe01d8..8c9935c0f 100644
> > --- a/lib/librte_vhost/vhost.c
> > +++ b/lib/librte_vhost/vhost.c
> > @@ -342,15 +342,21 @@ vhost_free_async_mem(struct vhost_virtqueue
> *vq)
> > {
> > if (vq->async_pkts_info)
> > rte_free(vq->async_pkts_info);
> > - if (vq->async_descs_split)
> > + if (vq->async_buffers_packed) {
> > + rte_free(vq->async_buffers_packed);
> > + vq->async_buffers_packed = NULL;
> > + }
> > + if (vq->async_descs_split) {
>
> You can remove the check, rte_free is safe with NULL pointers.
> You can do the same for the other ones in this function.
OK, it will be fixed.
>
> > rte_free(vq->async_descs_split);
> > + vq->async_descs_split = NULL;
> > + }
> > +
> > if (vq->it_pool)
> > rte_free(vq->it_pool);
> > if (vq->vec_pool)
> > rte_free(vq->vec_pool);
> >
> > vq->async_pkts_info = NULL;
> > - vq->async_descs_split = NULL;
> > vq->it_pool = NULL;
> > vq->vec_pool = NULL;
> > }
> > @@ -1627,9 +1633,9 @@ int rte_vhost_async_channel_register(int vid,
> uint16_t queue_id,
> > return -1;
> >
> > /* packed queue is not supported */
> > - if (unlikely(vq_is_packed(dev) || !f.async_inorder)) {
> > + if (unlikely(!f.async_inorder)) {
> > VHOST_LOG_CONFIG(ERR,
> > - "async copy is not supported on packed queue or
> non-inorder mode "
> > + "async copy is not supported on non-inorder mode "
> > "(vid %d, qid: %d)\n", vid, queue_id);
> > return -1;
> > }
> > @@ -1667,11 +1673,18 @@ int rte_vhost_async_channel_register(int vid,
> uint16_t queue_id,
> > vq->vec_pool = rte_malloc_socket(NULL,
> > VHOST_MAX_ASYNC_VEC * sizeof(struct iovec),
> > RTE_CACHE_LINE_SIZE, node);
> > - vq->async_descs_split = rte_malloc_socket(NULL,
> > + if (vq_is_packed(dev)) {
> > + vq->async_buffers_packed = rte_malloc_socket(NULL,
> > + vq->size * sizeof(struct vring_used_elem_packed),
> > + RTE_CACHE_LINE_SIZE, node);
> > + } else {
> > + vq->async_descs_split = rte_malloc_socket(NULL,
> > vq->size * sizeof(struct vring_used_elem),
> > RTE_CACHE_LINE_SIZE, node);
> > - if (!vq->async_descs_split || !vq->async_pkts_info ||
> > - !vq->it_pool || !vq->vec_pool) {
> > + }
> > +
> > + if (!vq->async_buffers_packed || !vq->async_descs_split ||
> > + !vq->async_pkts_info || !vq->it_pool || !vq->vec_pool) {
> > vhost_free_async_mem(vq);
> > VHOST_LOG_CONFIG(ERR,
> > "async register failed: cannot allocate
> memory for vq data "
> > diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h index
> > f628714c2..fe131ae8f 100644
> > --- a/lib/librte_vhost/vhost.h
> > +++ b/lib/librte_vhost/vhost.h
> > @@ -201,9 +201,14 @@ struct vhost_virtqueue {
> > uint16_tasync_pkts_idx;
> > uint16_tasync_pkts_inflight_n;
> > uint16_tasync_last_pkts_n;
> > - struct vring_used_elem *async_descs_split;
> > + union {
> > + struct vring_used_elem *async_descs_split;
> > + struct vring_used_elem_packed *async_buffers_packed;
> > + };
> > uint16_t async_desc_idx;
> > + uint16_t async_packed_buffer_idx;
>
> Don't dupplicate variable names, async_desc_idx can be reused for packed
> ring. Also, they are representing the same thing
[dpdk-dev] [PATCH 00/12] Bugfix for hns3 PMD
This set of patches contains 12 bugfixes for hns3 PMD. Chengchang Tang (2): net/hns3: fix potentially incorrect timing in MBX net/hns3: fix incorrect use of CMD status enumeration type Chengwen Feng (10): net/hns3: delete mailbox arq ring net/hns3: fix possible mismatches response of mailbox net/hns3: fix VF may report LSC event in secondary process net/hns3: fix miss verification of whether NEON supported net/hns3: fix missing outer L4 UDP flag for VXLAN packet net/hns3: add reporting TUNNEL GRE packet type net/hns3: fix PTP caps report net/hns3: rename Rx burst API net/hns3: add supported ptypes list for RXD advanced layout net/hns3: remove VLAN/QINQ ptypes from support list drivers/net/hns3/hns3_cmd.c| 17 ++- drivers/net/hns3/hns3_cmd.h| 9 +- drivers/net/hns3/hns3_ethdev.c | 12 +- drivers/net/hns3/hns3_ethdev.h | 1 - drivers/net/hns3/hns3_mbx.c| 282 + drivers/net/hns3/hns3_mbx.h| 34 ++--- drivers/net/hns3/hns3_rxtx.c | 97 ++ drivers/net/hns3/hns3_rxtx.h | 4 +- 8 files changed, 313 insertions(+), 143 deletions(-) -- 2.7.4
