Re: [PATCH] lib/gro: use hash function for flow lookup

On Wed, Jan 1, 2025 at 10:51 PM Stephen Hemminger < step...@networkplumber.org> wrote: > On Wed, 1 Jan 2025 15:07:35 +0530 > Kumara Parameshwaran wrote: > > > From: Kumara Parameshwaran > > To: hujiayu...@foxmail.com > > Cc: dev@dpdk.org, Kumara Parameshwaran > > Subject: [PATCH] lib/gro: use

Re: [PATCH v8] app/testpmd : fix packets not getting flushed in heavy-weight mode API

On Wed, Feb 21, 2024 at 11:32 PM Ferruh Yigit wrote: > On 2/16/2024 1:56 PM, Ferruh Yigit wrote: > > On 2/16/2024 3:47 AM, Kumara Parameshwaran wrote: > >> In heavy-weight mode GRO which is based on timer, the GRO packets > >> will not be flushed in spite of timer expiry if there is no packet > >

Re: [PATCH v9] gro: fix reordering of packets in GRO layer

On Thu, Jan 18, 2024 at 1:40 AM Kumara Parameshwaran < kumaraparames...@gmail.com> wrote: > In the current implementation when a packet is received with > special TCP flag(s) set, only that packet is delivered out of order. > There could be already coalesced packets in the GRO table > belonging to

Re: [PATCH v1] gro : packets not getting flushed in heavy-weight mode API

On Thu, Jan 18, 2024 at 1:22 AM Kumara Parameshwaran < kumaraparames...@gmail.com> wrote: > In heavy-weight mode GRO which is based on timer, the GRO packets will not > be > flushed inspite of timer expiry if there is no packet in the current poll. > If timer mode GRO is enabled the rte_gro_timeou

Re: [PATCH v11] gro: fix reordering of packets in GRO layer

On Sun, Jan 7, 2024 at 10:50 PM Stephen Hemminger < step...@networkplumber.org> wrote: > On Sun, 7 Jan 2024 16:59:20 +0530 > Kumara Parameshwaran wrote: > > > + /* Return early if the TCP flags are not handled in GRO layer */ > > + if (tcp_hdr->tcp_flags & (~(VALID_GRO_TCP_FLAGS))) > > N

Re: [PATCH] net/tap: add deprecation notice for RTE_FLOW_ACTION_RSS

On Fri, Dec 15, 2023, 8:31 AM Stephen Hemminger wrote: > On Fri, 15 Dec 2023 00:18:41 +0530 > kumaraparameshwaran rathinavel wrote: > > > On Thu, Dec 14, 2023, 11:20 PM Stephen Hemminger < > step...@networkplumber.org> > > wrote: > > > > > The BPF

Re: [PATCH] net/tap: add deprecation notice for RTE_FLOW_ACTION_RSS

On Thu, Dec 14, 2023, 11:20 PM Stephen Hemminger wrote: > The BPF infrastructure in kernel changed which broke the method > being used to load the RSS part of rte_flow in the TAP device. > Since this is a little used feature, and fixing the problem would > be moderately complex and create new dep

Re: RFC - GRO Flowlookup Optimisation

Phone > > > -- Original ------ > *From:* kumaraparameshwaran rathinavel > *Date:* Wed,Nov 22,2023 2:01 PM > *To:* dev , hujiayu.hu > *Subject:* Re: RFC - GRO Flowlookup Optimisation > > Hi Folks, > > The current GRO code uses an unoptimised versi

Re: RFC - GRO Flowlookup Optimisation

On Wed, Nov 22, 2023 at 4:05 PM Ferruh Yigit wrote: > On 11/22/2023 6:01 AM, kumaraparameshwaran rathinavel wrote: > > Hi Folks, > > > > The current GRO code uses an unoptimised version of flow lookup where > > each flow in the table is iterated over during the flow

RFC - GRO Flowlookup Optimisation

Hi Folks, The current GRO code uses an unoptimised version of flow lookup where each flow in the table is iterated over during the flow matching process. For a rte_gro_reassemble_burst in lightweight mode this would not cause much of an impact. But with rte_gro_reassemble which is done with a time

Re: [PATCH v5] gro : fix reordering of packets in GRO library

On Tue, Jun 20, 2023 at 1:06 PM Hu, Jiayu wrote: > Hi Kumara, > > Please see replies inline. > > Thanks, > Jiayu > > > -Original Message- > > From: Kumara Parameshwaran > > Sent: Tuesday, November 1, 2022 3:06 PM > > To: Hu, Jiayu > > Cc: dev@dpdk.org; Kumara Parameshwaran > > ; Kumara

Re: [PATCH v5] gro : fix reordering of packets in GRO library

Hi Jiayu, Thanks for the comments. I have replied inline below. Will address the review comments, but I think this would be a good patch to have in general. Please let me know your thoughts. On Tue, Jun 20, 2023 at 1:06 PM Hu, Jiayu wrote: > Hi Kumara, > > Please see replies inline. > > Thanks,

Re: [PATCH v9] gro : ipv6 changes to support GRO for TCP/ipv6

On Thu, Jun 15, 2023 at 1:31 PM Hu, Jiayu wrote: > Hi Kumara, > > > -Original Message- > > From: Kumara Parameshwaran > > Sent: Thursday, June 15, 2023 2:20 PM > > To: Hu, Jiayu > > Cc: dev@dpdk.org; Kumara Parameshwaran > > > > Subject: [PATCH v9] gro : ipv6 changes to support GRO for

Re: [PATCH v7] gro : ipv6 changes to support GRO for TCP/ipv6

On Tue, Jun 13, 2023 at 7:56 AM Hu, Jiayu wrote: > Hi Kumara, > > Overall, the patch looks good to me. But you need to update the doc and > there > are some minor changes needed to be made. Please see replies inline. > >> Thanks Jiayu. I see some linking errors for windows. It was a for >> ineser

Re: [PATCH v4] gro : ipv6 changes to support GRO for TCP/ipv6

Hi Jiyau, Thanks for the quick review comments. Will address the review comments. Require clarification in one of the comments. Please find it inline. On Thu, Jun 8, 2023 at 9:35 AM Hu, Jiayu wrote: > Hi Kumara, > > Please see replies inline. > > In addition, you need to update the programmer g

Re: [PATCH v3] gro : ipv6 changes to support GRO for TCP/ipv6

On Tue, Jun 6, 2023 at 10:05 AM Hu, Jiayu wrote: > Hi Kumara, > > The v3 patch is not complete and it seems to be a patch based on v2. > In addition, did you test the code for tcp4 and tcp6 after your change? > >> Will make sure that next patch contains the entire diff. >> > For others, please se

Re: Generic flow string parser

On Sun, Apr 30, 2023 at 3:10 AM Thomas Monjalon wrote: > This thread is an API suggestion, it should be discussed in > the developer mailing list (did the Cc here). > > 29/04/2023 16:23, Cliff Burdick: > > > Would rather the flow parser was rewritten as well. Doing open coded > > > parser is much

Re: [PATCH v2] gro : ipv6 changes to support GRO for TCP/ipv6

On Tue, May 16, 2023 at 2:58 PM kumaraparameshwaran rathinavel < kumaraparames...@gmail.com> wrote: > > > On Fri, May 12, 2023 at 8:17 AM Hu, Jiayu wrote: > >> Hi Kumar, >> >> For TCP/IPv4 and TCP/IPv6, the TCP layer is the same and the difference is >&

Re: [PATCH v2] gro : ipv6 changes to support GRO for TCP/ipv6

On Fri, May 12, 2023 at 8:17 AM Hu, Jiayu wrote: > Hi Kumar, > > For TCP/IPv4 and TCP/IPv6, the TCP layer is the same and the difference is > the IP layer. So the code used for TCP layer needs to be shared among > gro_tcp6.c > and gro_tcp4.c. But there are too much code duplication in gro_tcp4.c

Re: [PATCH] gro : ipv6 changes to support GRO for TCP/ipv6

Hi, I would like to get a review on the following patch where support is added for IPv6 GRO. Thanks, Param. On Thu, Oct 20, 2022 at 5:43 PM Kumara Parameshwaran < kumaraparames...@gmail.com> wrote: > From: Kumara Parameshwaran > > The patch adds GRO support for TCP/ipv6 packets. This does not

Re: [PATCH] gro : fix pkt length when extra bytes are padded to ethernet frame

Sent:* Wednesday, October 12, 2022 9:35 AM > *To:* kumaraparameshwaran rathinavel ; > dev@dpdk.org; David Marchand ; Hu, Jiayu < > jiayu...@intel.com> > *Subject:* RE: [PATCH] gro : fix pkt length when extra bytes are padded > to ethernet frame > > > > Yes, It's better to do it be

Re: [PATCH] gro : fix pkt length when extra bytes are padded to ethernet frame

. tcp_dl = pkt->pkt_len - hdr_len; >11. *if* (tcp_dl <= 0) >12. *return* -1; > > *From:* kumaraparameshwaran rathinavel > *Sent:* Tuesday, October 11, 2022 1:48 PM > *To:* dev@dpdk.org; David Marchand ; Hu, Jiayu > ; Jun Qiu > *Subject:* Fwd: [PATCH] gro : fix

Fwd: [PATCH] gro : fix pkt length when extra bytes are padded to ethernet frame

On Tue, Oct 11, 2022 at 1:03 AM David Marchand wrote: > On Mon, Oct 10, 2022 at 7:51 PM Kumara Parameshwaran > wrote: > > > > From: Kumara Parameshwaran > > > > When GRO packets are merged the packet length is used while > > merging the adjacent packets. If the padded bytes are accounted > > we

Re: GRO Support for IPv6

Thanks Jiyau. I would then like to add support for it. On Tue, Oct 11, 2022 at 6:51 AM Hu, Jiayu wrote: > Hi Kumara, > > > > No plan to support IPv6 in my side. > > > > Thanks, > > Jiayu > > > > *From:* kumaraparameshwaran rathinavel > *Sent

GRO Support for IPv6

Hi Everyone, We would require GRO support for IPv6 in our product. I see that the current GRO library does not support it, is anyone working on it? If not, I would like to contribute. Please let me know your thoughts. Thanks, Kumara.

Fwd: GRO Enhancement Proposal

Hi Jiyay, Please let me know the thoughts. Thanks, Kumara -- Forwarded message - From: kumaraparameshwaran rathinavel Date: Fri, Jul 22, 2022 at 2:05 PM Subject: GRO Enhancement Proposal To: Cc: Hu, Jiayu , Ferruh Yigit Hi Everyone, I am thinking of a few enhancements to

Re: [PATCH] gro: fix gro with tcp push flag

merged > > > > *发件人:* kumaraparameshwaran rathinavel > *发送时间:* 2022年7月26日 14:41 > *收件人:* Jun Qiu > *抄送:* dev@dpdk.org; jiayu...@intel.com; sta...@dpdk.org > *主题:* Re: [PATCH] gro: fix gro with tcp push flag > > > > > > > > On Tue, Jul 26, 2022 at 1

Re: [PATCH] gro: fix gro with tcp push flag

On Tue, Jul 26, 2022 at 11:48 AM Jun Qiu wrote: > TCP data packets sometimes carry a PUSH flag. Currently, > only the packets that do not have PUSH flag can be GROed. > The packets that have a PUSH flag cannot be GROed, the packets > that cannot be processed by GRO are placed last. > In this case

GRO Enhancement Proposal

Hi Everyone, I am thinking of a few enhancements to the existing GRO library and I have listed them below, 1. The current implementation for the TCP in GRO disregards the PSH flag and delivers it immediately in the current burst. But this would lead to reordering of packets if there wer

Re: [PATCH v1] gro: bug fix in identifying 0 length tcp packets

? Thanks, Param On Mon, Apr 25, 2022 at 11:36 PM kumaraparameshwaran rathinavel < kumaraparames...@gmail.com> wrote: > Hi, > > I would like you to review this patch and let me know what you think of > it. > > Thanks, > Kumara. > > -- Forwarded message -

Re: [PATCH v4] gro: bug fix in identifying fragmented packets

t; > l2/l3/l4 headers. TCP GSO doesn’t use MF flag and offset field in IP > header but use > > sequence number to reassemble. > > > > The case you mentioned below is IP fragmentation, not UDP GSO or TCP GSO. > > > > Thanks, > > Jiayu > > *From:* kumarapar

Re: [PATCH v4] gro: bug fix in identifying fragmented packets

> -Original Message- > From: Kumara Parameshwaran > Sent: Wednesday, June 8, 2022 5:57 PM > To: Hu, Jiayu > Cc: dev@dpdk.org; Kumara Parameshwaran > ; sta...@dpdk.org > Subject: [PATCH v4] gro: bug fix in identifying fragmented packets > > From: Kumara Parameshwaran > > A packet with RTE

UDP-GRO not working

Hi , I tried using the UDP GRO feature in DPDK recently and it did not see working. I understand the GRO for UDP is applicable only for fragmented packets, there is the following check in gro_udp4.c /* * Don't process non-fragment packet. */ if (!is_ipv4_fragment(ipv4_hdr)) return -1; There look

Re: [PATCH v1] drivers/net: use internal API to get eth dev from name

Ferruh, Since in the older patch we had introduced rte_eth_dev_get_by_name patch and had been merged to dpdk-next-net, the current patch failed for the build when I submitted the patch. Is there a way to enforce it to dpdk-next-net ? On Thu, Feb 3, 2022 at 1:54 PM Kumara Parameshwaran < kumarapar

Re: [Bug 932] tap stop fails because of 'tap_lsc_intr_handle_set()' failure

On Tue, Feb 1, 2022, 10:34 PM wrote: > https://bugs.dpdk.org/show_bug.cgi?id=932 > > Bug ID: 932 >Summary: tap stop fails because of 'tap_lsc_intr_handle_set()' > failure >Product: DPDK >Version: 20.11 > Hardware: All >

Re: [PATCH v2] net/tap: fix to populate fds in secondary process

Hi Ferruh, Please find the consolidated comments for the review. I had missed answering a few of them in my previous email. On Mon, Jan 24, 2022 at 6:05 PM Ferruh Yigit wrote: > On 1/24/2022 12:12 PM, Kumara Parameshwaran wrote: > > From: Kumara Parameshwaran > > > > When a tap device is hotpl

Re: [PATCH v2] net/tap: fix to populate fds in secondary process

On Mon, Jan 24, 2022 at 6:05 PM Ferruh Yigit wrote: > On 1/24/2022 12:12 PM, Kumara Parameshwaran wrote: > > From: Kumara Parameshwaran > > > > When a tap device is hotplugged to primary process which in turn > > adds the device to all secondary process, the secondary process > > does a tap_mp_a

Re: [PATCH] net/tap: Bug fix to populate fds in secondary process

On Tue, Jan 18, 2022 at 9:51 PM Stephen Hemminger < step...@networkplumber.org> wrote: > On Tue, 18 Jan 2022 05:22:19 + > Kumara Parameshwaran wrote: > > > @Stephen Hemminger This is process > private as the tap fds are maintained in per process data structu

Re: [PATCH] net/tap: Bug fix to populate fds in secondary process

Just wanted to bring it to your attention, In Mellanox driver there is a requirement to exchange fds between primary and secondary and similar usage is seen, the primary sends the port_id and the secondary refers to the rte_eth_devices in the driver, The functions are - mlx5_mp_secondar

Re: [PATCH] net/tap: Bug fix to populate fds in secondary process

Yes, even I was confused if it had been the tap_intr_handle_set function. In general the tap_dev_start should not be invoked by the secondary and only primary should do it. I referred it to a couple of PMDs and that was the case. Please let me know if I am missing something in my understanding.

[dpdk-dev] Failsafe Secondary Process

Hi All, In the commit ee27edbe0c10ec8337c4cc4d2935a751d0da605f I see that for the probe from the secondary process the below check was made, for vdev devices like tap, af_packet. + if (rte_eal_process_type() == RTE_PROC_SECONDARY && + strlen(rte_vdev_device_args(dev)) == 0) { +

[dpdk-dev] rte_fbarray with Legacy mem

Hi All, I am facing an issue with 20.05 when legacy mem is being used. These are the logs added to the remap_segment function during eal_legacy_hugepage_init and found below EAL: remap_segment memseg_len:2097152 ms_idx:1095 msl->base_va:0x6020 post-addr:0x60008900 physaddr:21600

[dpdk-dev] GRO-Flow-Chaining

Hi All, I just need few clarifications in the GRO code that is present In the below code where the merge fails because the IP length is greater than 65536 we do a insert_new_item but we send prev_idx rather than the cur_idx. This would work for index 0 and 1 but when cur_idx is 1 and merge fails,

[dpdk-dev] VIRTIO PMD DRVIER

Hi All, In drivers/net/virtio/virtio_ethdev.c, I see that that drv_flags is set to 0 and not other flags (RTE_PCI_DRV_NEED_MAPPING). Is this intended? I understand internally that when the vtpci_init is called the mapping is done. Is the value set to 0 to avoid mapping two times? 2170 static str

[dpdk-dev] DPDK-VIRTIO- GCP- RSS

Hi All, I tried using multiqueue in DPDK GCP. But I am facing issues where descriptor index between guest and hypervisor going out of sync. Basically when device notifies rx but the mbuf cookie at that index is NULL. Please let me know if there are known limitations in using GCP RSS. I have two q

[dpdk-dev] VIRTIO DPDK

Hi All, We are using 16.04 version of DPDK and I am using the virtio driver in the guest VM which uses virtio_recv_mergeable_pkts in the rx_code path and I am thinking that there can be an infinite loop. Please let me know if this could happen and was there any bugs reported related to this and I

[dpdk-dev] Virtio MultiQueue

Hi All, I am using virtio DPDK PMD with multiqueue feature and I am facing the issue where the packets of a flow aren't coming to the same RX queue, looks like it is being received randomly. On the host side I am using OpenVswitch. Please let me know if there is something to be done from the DPDK

Re: [dpdk-dev] Admin Queue ENA

o the rte_eth_stats_get()? > > Another solution might be using xstats API, which should let you to > get statistics from multiple threads as it's not using admin queue for > that - all stats are being counter internally in the PMD. > > Thanks, > Michal > > > pt.,

Re: [dpdk-dev] Admin Queue ENA

om_get_dev_basic_stats(), which > is called from rte_eth_stats_get() context - but if you consider DPDK > application, it should use it on the management lcore after init, so > it'll also be serialized. > > Thanks, > Michal > > > > pt., 8 lis 2019 o 07:02 kumar

Re: [dpdk-dev] Admin Queue ENA

not under this spin lock. Thanks, Param On Thu, Oct 24, 2019 at 2:09 PM Michał Krawczyk wrote: > sob., 19 paź 2019 o 20:26 kumaraparameshwaran rathinavel > napisał(a): > > > > Hi All, > > > > In the ENA poll mode driver I see that every request in the admin queue > is

[dpdk-dev] Admin Queue ENA

Hi All, In the ENA poll mode driver I see that every request in the admin queue is associated with a completion context and this is preallocated during the device initialisation. When the completion context is used we check for occupied to be true in the 16.X version if the occupied flag is set to

[dpdk-dev] Forking Secondary Process

Hi All, I have a requirement where I would need to fork secondary process from a primary process. In the latest implementation of DPDK is this model supported?. Meaning in the parent process I would do rte_eal_init as primary and in the child processes, I would invoke rte_eal_init as secondary pro

[dpdk-dev] DPDK Virtio Checksum Errors

Hi All, I had recently tried using TSO on the DPDK virtio guest driver and I get the TCP checksum errors at the client side. I tried running iperf and Apache bench We have been using the same TCP/IP stack for other DPDK pmd drivers and they are working fine. I did notice that incase of virtio alo