optimize the GRO lookup using hash based
implementation
Signed-off-by: Kumara Parameshwaran
---
The patch helps improving the CPU cycles during flow lookup in the GRO library.
The current approach iterates over all the flows in the GRO table to find a
matching flow for every incoming packet
If there are no packets flushed in GRO heavy weight mode,
return false as this fall through code would return true
indicating that packets are available
Fixes: 461c287ab553 ("app/testpmd: fix GRO packets flush on timeout")
Cc: sta...@dpdk.org
Signed-off-by: Kumara Parameshwaran
---
mode TCP/IPv4 GRO")
Cc: hujiayu...@foxmail.com
Signed-off-by: Kumara Parameshwaran
---
v1:
Changes to make sure that the GRO flush API is invoked if there are no
packets in
current poll and timer expiry.
v2:
Fix code organisation issue
v3:
Fix warnings
v4:
Fix error an
mode TCP/IPv4 GRO")
Cc: jiayu...@intel.com
Signed-off-by: Kumara Parameshwaran
---
v1:
Changes to make sure that the GRO flush API is invoked if there are no
packets in
current poll and timer expiry.
v2:
Fix code organisation issue
v3:
Fix warnings
v4:
Fix error and wa
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
in the current poll. If timer mode GRO is enabled the
rte_gro_timeout_flush API should be invoked.
Signed-off-by: Kumara Parameshwaran
---
v1:
Changes to make
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
in the current poll. If timer mode GRO is enabled the
rte_gro_timeout_flush API should be invoked.
Signed-off-by: Kumara Parameshwaran
---
v1:
Changes to make
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 in the current poll.
If timer mode GRO is enabled the rte_gro_timeout_flush API should be invoked.
Signed-off-by: Kumara Parameshwaran
---
v1:
Changes to make
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_timeout_flush API should be invoked.
Signed-off-by: Kumara Parameshwaran
---
v1:
Changes to make
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_timeout_flush API should be invoked.
Signed-off-by: Kumara Parameshwaran
---
v1:
Changes to make
the
special flag(s) set which is how the Linux GRO is also implemented
Signed-off-by: Kumara Parameshwaran
Co-authored-by: Kumara Parameshwaran
---
If the received packet is not a pure ACK packet, we check if
there are any previous packets in the flow, if present we indulge
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_timeout_flush API should be invoked.
Signed-off-by: Kumara Parameshwaran
---
v1:
Changes to make
the
special flag(s) set which is how the Linux GRO is also implemented
Signed-off-by: Kumara Parameshwaran
---
If the received packet is not a pure ACK packet, we check if
there are any previous packets in the flow, if present we indulge
the received packet also in the
the
special flag(s) set which is how the Linux GRO is also implemented
Signed-off-by: Kumara Parameshwaran
---
If the received packet is not a pure ACK packet, we check if
there are any previous packets in the flow, if present we indulge
the received packet also in the
the
special flag(s) set which is how the Linux GRO is also implemented
Signed-off-by: Kumara Parameshwaran
---
If the received packet is not a pure ACK packet, we check if
there are any previous packets in the flow, if present we indulge
the received packet also in the
the
special flag(s) set which is how the Linux GRO is also implemented
Signed-off-by: Kumara Parameshwaran
Co-authored-by: Kumara Parameshwaran
---
If the received packet is not a pure ACK packet, we check if
there are any previous packets in the flow, if present we indulge
the
special flag(s) set which is how the Linux GRO is also implemented
Signed-off-by: Kumara Parameshwaran
Co-authored-by: Kumara Parameshwaran
---
If the received packet is not a pure ACK packet, we check if
there are any previous packets in the flow, if present we indulge
special flag(s) set which is how the Linux GRO is also implemented
Signed-off-by: Kumara Parameshwaran
Co-authored-by: Kumara Parameshwaran
---
If the received packet is not a pure ACK packet, we check if
there are any previous packets in the flow, if present we indulge
the
special flag(s) set which is how the Linux GRO is also implemented
Signed-off-by: Kumara Parameshwaran
Co-authored-by: Kumara Parameshwaran
---
If the received packet is not a pure ACK packet, we check if
there are any previous packets in the flow, if present we indulge
the
special flag(s) set which is how the Linux GRO is also implemented
Signed-off-by: Kumara Parameshwaran
Co-authored-by: Kumara Parameshwaran
---
If the received packet is not a pure ACK packet, we check if
there are any previous packets in the flow, if present we indulge
the
Add support for IPv6 GRO for TCP packets
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only for ipv6 packets that does not contain
extension headers
Refactor the existing code to reuse data strutures and functions
to add support for IPv6 GRO
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only for ipv6 packets
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only for ipv6 packets that does not contain
extension headers.
* The logic for the TCP coalescing
Refactor the existing code to reuse data strutures and functions
to add support for IPv6 GRO
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only for ipv6 packets
The patch adds GRO support for TCP/ipv6 packets. This does not
include the support for vxlan, udp ipv6 packets.
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only
The patch adds GRO support for TCP/ipv6 packets. This does not
include the support for vxlan, udp ipv6 packets.
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only
The patch adds GRO support for TCP/ipv6 packets. This does not
include the support for vxlan, udp ipv6 packets.
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only
The patch adds GRO support for TCP/ipv6 packets. This does not
include the support for vxlan, udp ipv6 packets.
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only
The patch adds GRO support for TCP/ipv6 packets. This does not
include the support for vxlan, udp ipv6 packets.
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only
The patch adds GRO support for TCP/ipv6 packets. This does not
include the support for vxlan, udp ipv6 packets.
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only
The patch adds GRO support for TCP/ipv6 packets. This does not
include the support for vxlan, udp ipv6 packets.
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes.
* The GRO is performed only for ipv6 packets that does not contain
extension headers.
* The logic for the TCP coalescing
From: Kumara Parameshwaran
When a TCP packet contains flags like PSH it is returned
immediately to the application though there might be packets of
the same flow in the GRO table. If PSH flag is set on a segment
packets up to the segment should be delivered immediately. But the
current
From: Kumara Parameshwaran
When a TCP packet contains flags like PSH it is returned
immediately to the application though there might be packets of
the same flow in the GRO table. If PSH flag is set on a segment
packets up to the segment should be delivered immediately. But the
current
From: Kumara Parameshwaran
When a TCP packet contains flags like PSH it is returned
immediately to the application though there might be packets of
the same flow in the GRO table. If PSH flag is set on a segment
packets up to the segment should be delivered immediately. But the
current
From: Kumara Parameshwaran
When a TCP packet contains flags like PSH it is returned
immediately to the application though there might be packets of
the same flow in the GRO table. If PSH flag is set on a segment
packets up to the segment should be delivered immediately. But the
current
From: Kumara Parameshwaran
When a TCP packet contains flags like PSH it is returned
immediately to the application though there might be packets of
the same flow in the GRO table. If PSH flag is set on a segment
packets up to the segment should be delivered immediately. But the
current
From: Kumara Parameshwaran
The patch adds GRO support for TCP/ipv6 packets. This does not
include the support for vxlan, udp ipv6 packets.
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes
From: Kumara Parameshwaran
The patch adds GRO support for TCP/ipv6 packets. This does not
include the support for vxlan, udp ipv6 packets.
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes
From: Kumara Parameshwaran
The patch adds GRO support for TCP/ipv6 packets. This does not
include the support for vxlan, udp ipv6 packets.
Signed-off-by: Kumara Parameshwaran
---
v1:
* Changes to support GRO for TCP/ipv6 packets. This does not include
vxlan changes
From: Kumara Parameshwaran
When packet is padded with extra bytes the
the validation of the payload length should be done
after the trim operation
Fixes: b8a55871d5af ("gro: trim tail padding bytes")
Cc: sta...@dpdk.org
Signed-off-by: Kumara Parameshwaran
---
v1:
If there
From: Kumara Parameshwaran
When a TCP packet contains flags like PSH it is returned
immediately to the application though there might be packets of
the same flow in the GRO table. If PSH flag is set on a segment
packets upto the segment should be delivered immediately. But the
current
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 would end up acking unsent TCP segments.
Signed-off-by: Kumara Parameshwaran
v1:
If there is padding to the ethernet frame cases
From: Kumara Parameshwaran
When more than two packets are merged in a flow, and if we receive
a 3rd packet which is matching the sequence of the 2nd packet the
prev_idx will be 1 and not 2, hence resulting in packet re-ordering
Signed-off-by: Kumara Parameshwaran
---
V1:
Initial
From: Kumara Parameshwaran
When more than two packets are merged in a flow, and if we receive
a 3rd packet which is matching the sequence of the 2nd packet the
prev_idx will be 1 and not 2, hence resulting in packet re-ordering
Signed-off-by: Kumara Parameshwaran
---
V1:
Initial
From: Kumara Parameshwaran
A packet with RTE_PTYPE_L4_FRAG(0x300) contains both RTE_PTYPE_L4_TCP
(0x100) & RTE_PTYPE_L4_UDP (0x200). A fragmented packet as defined in
rte_mbuf_ptype.h cannot be recognized as other L4 types and hence the
GRO layer should not use IS_IPV4_TCP_PKT or IS_IPV4_UDP
From: Kumara Parameshwaran
A packet with RTE_PTYPE_L4_FRAG(0x300) contains both RTE_PTYPE_L4_TCP
(0x100) & RTE_PTYPE_L4_UDP (0x200). A fragmented packet as defined in
rte_mbuf_ptype.h cannot be recognized as other L4 types and hence the
GRO layer should not use IS_IPV4_TCP_PKT or IS_IPV4_UDP
From: Kumara Parameshwaran
A packet with RTE_PTYPE_L4_FRAG(0x300) contains both RTE_PTYPE_L4_TCP
(0x100) & RTE_PTYPE_L4_UDP (0x200). A fragmented packet as defined in
rte_mbuf_ptype.h cannot be recognized as other L4 types and hence the
GRO layer should not use IS_IPV4_TCP_PKT or IS_IPV4_UDP
From: Kumara Parameshwaran
As the minimum Ethernet frame size is 64 bytes, a 0 length
tcp payload without tcp options would be 54 bytes and hence
there would be padding. So it would be incorrect to use the
packet length to determine the tcp data length.
Fixes: 1e4cf4d6d4fb ("gro: cleanup
From: Kumara Parameshwaran
As the minimum Ethernet frame size is 64 bytes, a 0 length
tcp payload without tcp options would be 54 bytes and hence
there would be padding. So it would be incorrect to use the
packet length to determine the tcp data length.
Fixes: 1e4cf4d6d4fb ("gro: cleanup
From: Kumara Parameshwaran
As the minimum Ethernet frame size is 64 bytes, a 0 length
tcp payload without tcp options would be 54 bytes and hence
there would be padding. So it would be incorrect to use the
packet length to determine the tcp data length.
Fixes: 1e4cf4d6d4fb ("gro: cleanup
Signed-off-by: Kumara Parameshwaran
---
v1:
Do not use packet length to determine the tcp data length as
the packet length could have padded bytes. This would lead
to addition of 0 length tcp packets into the GRO layer when
there ethernet fram is padded.
lib/gro/
From: Kumara Parameshwaran
A packet with RTE_PTYPE_L4_FRAG(0x300) contains both RTE_PTYPE_L4_TCP
(0x100) & RTE_PTYPE_L4_UDP (0x200). A fragmented packet as defined in
rte_mbuf_ptype.h cannot be recognized as other L4 types and hence the
GRO layer should not use IS_IPV4_TCP_PKT or IS_IPV4_UDP
From: Kumara Parameshwaran
A packet with RTE_PTYPE_L4_FRAG(0x300) contains both RTE_PTYPE_L4_TCP
(0x100) & RTE_PTYPE_L4_UDP (0x200). A fragmented packet as defined in
rte_mbuf_ptype.h cannot be recognized as other L4 types and hence the
GRO layer should not use IS_IPV4_TCP_PKT or IS_IPV4_UDP
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 lo
From: Kumara Parameshwaran
Make changes in PMDs to use the new function where
rte_eth_dev_get_port_by_name is used to get port_id
to access rte_eth_devices
Signed-off-by: Kumara Parameshwaran
---
v1
* Replace rte_eth_get_get_port_by_name in PMDs with rte_eth_dev_get_by_name
where port_id is
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_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added
From: Kumara Parameshwaran
The PMDs would need a function to access the rte_eth_devices
global array
Cc: sta...@dpdk.org
Signed-off-by: Kumara Parameshwaran
---
lib/ethdev/ethdev_driver.h | 18 ++
lib/ethdev/rte_ethdev.c| 11 +++
lib/ethdev/version.map | 1
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_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added
From: Kumara Parameshwaran
The PMDs would need a function to access the rte_eth_devices
global array
Cc:sta...@dpdk.org
Signed-off-by: Kumara Parameshwaran
---
lib/ethdev/ethdev_driver.h | 18 ++
lib/ethdev/rte_ethdev.c| 11 +++
lib/ethdev/version.map | 1
From: Ferruh Yigit
Sent: 24 January 2022 18:05
To: Kumara Parameshwaran ; dev@dpdk.org
Cc: Kumara Parameshwaran ; sta...@dpdk.org
Subject: Re: [PATCH v2] net/tap: fix to populate fds in secondary process
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_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added
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_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added
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_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added
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_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added
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_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added
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_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added
inger
Sent: 18 January 2022 03:46
To: Kumara Parameshwaran
Cc: keith.wi...@intel.com ; dev@dpdk.org ;
Kumara Parameshwaran
Subject: Re: [PATCH] net/tap: Bug fix to populate fds in secondary process
On Fri, 26 Nov 2021 09:45:15 +0530
Kumara Parameshwaran wrote:
> + ret = rte_eth_dev_ge
From: Ferruh Yigit
Sent: 17 January 2022 23:52
To: Kumara Parameshwaran ; keith.wi...@intel.com
Cc: dev@dpdk.org ; Kumara Parameshwaran
; Raslan Darawsheh
Subject: Re: [PATCH] net/tap: Bug fix to populate fds in secondary process
On 11/26/2021 4:15 AM
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_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added
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_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added
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_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added
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_attach_queues, but the fds are are not populated in
the primary during the probe they are populated during the queue_setup
ndary process")
Cc: qi.z.zh...@intel.com
Signed-off-by: Kumara Parameshwaran
---
drivers/net/failsafe/failsafe.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/failsafe/failsafe.c b/drivers/net/failsafe/failsafe.c
index ad6b43538e..3c754a5f66 100644
--- a/d
Remove the vdev args check for secondary process which prevents the
secondary from attaching to the device created by the primary process
via the hotplug framework. This check was removed for other vdevs but
was missed for failsafe.
Signed-off-by: Kumara Parameshwaran
---
drivers/net/failsafe
Remove the vdev args check for secondary process which prevents the secondary
from attaching
to the device created by the primary process via the hotplug framework. This
check was removed
for other vdevs but was missed for failsafe.
Signed-off-by: Kumara Parameshwaran
---
drivers/net/failsafe
Remove the vdev args check for secondary process which prevents the secondary
from attaching
to the device created by the primary process via the hotplug framework. This
check was removed
for other vdevs but was missed for failsafe.
Signed-off-by: Kumara Parameshwaran
---
drivers/net/failsafe
Remove the vdev args check for secondary process which prevents the secondary
from attaching
to the device created by the primary process via the hotplug framework. This
check was removed
for other vdevs but was missed for failsafe.
Signed-off-by: Kumara Parameshwaran
---
drivers/net/failsafe
Remove the vdev args check for secondary process which prevents the secondary
from attaching
to the device created by the primary process via the hotplug framework. This
check was removed
for other vdevs but was missed for failsafe.
Signed-off-by: Kumara Parameshwaran
---
drivers/net/failsafe
Signed-off-by: Kumara Parameshwaran
---
drivers/net/failsafe/failsafe.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/failsafe/failsafe.c b/drivers/net/failsafe/failsafe.c
index ad6b43538e..3c754a5f66 100644
--- a/drivers/net/failsafe/failsafe.c
+++ b/drivers
Signed-off-by: Kumara Parameshwaran
---
drivers/net/failsafe/failsafe.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/failsafe/failsafe.c b/drivers/net/failsafe/failsafe.c
index 8216063..1adccaf 100644
--- a/drivers/net/failsafe/failsafe.c
+++ b/drivers/net
Hi,
Recently I was using the failsafe PMD with multi process scenario and found the
secondary process was not working as expected. . I saw you were mentioned as
the maintainer for this PMD.
I have attached the patch, please let me know if this is okay.
I think in the following commit, the fail
81 matches
Mail list logo
