At 2021-01-15 18:24:47, "Thomas Monjalon" wrote:
>15/01/2021 04:51, yang_y_yi:
>>
>> At 2020-11-19 14:49:23, "Hu, Jiayu" wrote:
>> >Acked-by: Jiayu Hu
>>
>> Hi, Thomas
>>
>> This patch has been acked very long, but
At 2020-11-19 14:49:23, "Hu, Jiayu" wrote:
>Acked-by: Jiayu Hu
Hi, Thomas
This patch has been acked very long, but it isn't merged into master, what's
wrong?
>
>> -Original Message-
>> From: yang_y...@163.com
>> Sent: Thursday, November 19, 2020 2:44 PM
>> To: dev@dpdk.org
>> Cc: H
From: Yi Yang
IPv6 VXLAN UDP/IPv6 GRO can help improve UDP/IPv6
performance in IPv6 VXLAN use case.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM UDP/IPv6 performance, it will merge
small adjacent IPv6 VXLAN UDP/IPv6 fragments to a big
IPv6 VXLAN UDP/IPv6 packet immedia
From: Yi Yang
IPv6 VXLAN UDP/IPv4 GRO can help improve UDP/IPv4
performance in IPv6 VXLAN use case.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM UDP/IPv4 performance, it will merge
small adjacent IPv6 VXLAN UDP/IPv4 fragments to a big
IPv6 VXLAN UDP/IPv4 packet immedia
From: Yi Yang
IPv6 VXLAN TCP/IPv6 GRO can help improve TCP/IPv6 performance
in IPv6 VXLAN use case.
With this enabled in DPDK, OVS DPDK can leverage it to improve
VM-to-VM TCP/IPv6 performance, it will merge small adjacent
IPv6 VXLAN TCP/IPv6 packets to a big IPv6 VXLAN TCP/IPv6 packet
immediate
From: Yi Yang
IPv4 VXLAN UDP/IPv6 GRO can help improve UDP/IPv6
performance in IPv4 VXLAN use case.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM UDP/IPv6 performance, it will merge
small adjacent IPv4 VXLAN UDP/IPv6 fragments to a big
IPv4 VXLAN UDP/IPv6 packet immedia
From: Yi Yang
UDP/IPv6 GRO can help improve UDP/IPv6 performance.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM UDP/IPv6 performance, it will merge
small adjacent UDP/IPv6 fragments to a big UDP/IPv6 packet
immediate after they are received from a physical NIC. It
is ve
From: Yi Yang
IPv4 VXLAN TCP/IPv6 GRO can help improve TCP/IPv6 performance
in IPv4 VXLAN use case.
With this enabled in DPDK, OVS DPDK can leverage it to improve
VM-to-VM TCP/IPv6 performance, it will merge small adjacent
IPv4 VXLAN TCP/IPv6 packets to a big IPv4 VXLAN TCP/IPv6 packet
immediate
From: Yi Yang
TCP/IPv6 GRO can help improve TCP/IPv6 performance.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM TCP/IPv6 performance, it will merge
small adjacent TCP/IPv6 segments to a big TCP/IPv6 segment
immediate after they are received from a physical NIC. It
is ve
From: Yi Yang
IPv6 VXLAN TCP/IPv4 GRO can help improve TCP/IPv4 performance
in IPv6 VXLAN use case.
With this enabled in DPDK, OVS DPDK can leverage it to improve
VM-to-VM TCP/IPv4 performance, it will merge small adjacent
IPv6 VXLAN TCP/IPv4 packets to a big IPv6 VXLAN TCP/IPv4 packet
immediate
From: Yi Yang
In production system, both IPv4 and IPv6 are required, this patch
series added TCP/IPv6 and UDP/IPv6 gro support for both VLAN and
VXLAN use cases, with this patch seiries applied, DPDK can support gro
for all the below cases:
VLAN TCP/IPv4
VLAN UDP/IPv4
VLAN TCP/IPv6
VLAN UDP/IPv6
From: Yi Yang
As most NICs do not support segmentation for VXLAN-encapsulated
UDP/IPv4 packets, this patch adds VXLAN UDP/IPv4 GSO support.
OVS DPDK can significantly improve VXLAN UDP/IPv4 performance by
VXLAN UDP/IPv4 GSO.
Signed-off-by: Yi Yang
---
Changelog:
v3 -> v4:
- Use more precise
From: Yi Yang
Many NICs can't offload VXLAN UFO, so it is very important
to do VXLAN UDP GSO by software to improve VM-to-VM UDP
performance, especially for the case that VM MTU is just
1500 but not 9000.
With this enabled in DPDK, OVS DPDK can leverage it to
improve VM-to-VM UDP performance, pe
At 2020-11-13 21:16:38, "Ananyev, Konstantin"
wrote:
>...
>> diff --git a/lib/librte_gso/rte_gso.c b/lib/librte_gso/rte_gso.c
>> index 896350e..fb76a21 100644
>> --- a/lib/librte_gso/rte_gso.c
>> +++ b/lib/librte_gso/rte_gso.c
>> @@ -11,6 +11,7 @@
>> #include "gso_common.h"
>> #include "gso_tcp
From: Yi Yang
Many NICs can't offload VXLAN UFO, so it is very important
to do VXLAN UDP GSO by software to improve VM-to-VM UDP
performance, especially for the case that VM MTU is just
1500 but not 9000.
With this enabled in DPDK, OVS DPDK can leverage it to
improve VM-to-VM UDP performance, pe
At 2020-11-06 12:09:16, "Jiayu Hu" wrote:
>On Thu, Oct 29, 2020 at 02:47:43PM +0800, yang_y...@163.com wrote:
>> From: Yi Yang
>>
>> Many NICs can't offload VXLAN UFO, so it is very important
>> to do VXLAN UDP GSO by software to improve VM-to-VM UDP
>> performance, especially for the case that
From: Yi Yang
For VxLAN packets, GRO will mistakenly reassemble them
if inner L3 is IPv6, inner L4 is TCP or UDP, and outer L3
is IPv4 because the value of IS_IPV4_VXLAN_TCP4/UDP4_PKT
is true for them.
This fix makes sure IS_IPV4_TCP_PKT, IS_IPV4_UDP_PKT,
IS_IPV4_VXLAN_TCP4_PKT and IS_IPV4_VXLA
At 2020-11-05 09:41:13, "Hu, Jiayu" wrote:
>Hi Yi,
>
>> -Original Message-
>> From: yang_y...@163.com
>> Sent: Wednesday, November 4, 2020 12:23 PM
>> To: dev@dpdk.org
>> Cc: Hu, Jiayu ; Ananyev, Konstantin
>> ; tho...@monjalon.net;
>> yangy...@inspur.com; yang_y...@163.com
>> Subject: [P
From: Yi Yang
Current code will think IPv6 packet as IPv4 packet
if inner header is IPv6 and outer header is IPv4,
the result is rte_gro_reassemble() will handle it
as if inner header also is IPv4, so IPv6 can't
be handled correctly as one of unprocess_pkts.
Fixes: e2d811063673 ("gro: support VX
At 2020-11-04 05:34:52, "Thomas Monjalon" wrote:
>29/10/2020 22:39, Thomas Monjalon:
>> I don't have a clear opinion on this patch.
>> Techboard members, ping for feedbacks.
>> If no objection, I will merge it soon, but I would prefer having more acks.
>>
>>
>> 27/10/2020 20:55, Ananyev, Konstan
From: Yi Yang
Many NICs can't offload VXLAN UFO, so it is very important
to do VXLAN UDP GSO by software to improve VM-to-VM UDP
performance, especially for the case that VM MTU is just
1500 but not 9000.
With this enabled in DPDK, OVS DPDK can leverage it to
improve VM-to-VM UDP performance, pe
From: Yi Yang
rte_gso_segment decreased refcnt of pkt by one, but
it is wrong if pkt is external mbuf, pkt won't be
freed because of incorrect refcnt, the result is
application can't allocate mbuf from mempool because
mbufs in mempool are run out of.
One correct way is application should call
rt
At 2020-10-26 10:06:09, "Jiayu Hu" wrote:
>On Mon, Oct 26, 2020 at 08:57:30AM +0800, yang_y_yi wrote:
>> At 2020-10-23 22:46:42, "Ananyev, Konstantin"
>> wrote:
>>
>> >> From: yang_y_yi
>> >> Sent: Friday, October 23, 2020
At 2020-10-23 22:46:42, "Ananyev, Konstantin"
wrote:
>> From: yang_y_yi
>> Sent: Friday, October 23, 2020 2:18 PM
>> To: Ananyev, Konstantin
>> Cc: dev@dpdk.org; Hu, Jiayu ; techbo...@dpdk.org;
>> tho...@monjalon.net; yangy...@inspur.com
>> Sub
At 2020-10-23 08:57:15, "Hu, Jiayu" wrote:
>
>
>> -Original Message-
>> From: Ananyev, Konstantin
>> Sent: Thursday, October 22, 2020 11:34 PM
>> To: yang_y...@163.com; dev@dpdk.org
>> Cc: Hu, Jiayu ; techbo...@dpdk.org;
>> tho...@monjalon.net; yangy...@inspur.com
>> Subject: RE: [PATCH v
At 2020-10-22 23:33:42, "Ananyev, Konstantin"
wrote:
>
>> >
>> > rte_gso_segment decreased refcnt of pkt by one, but
>> > it is wrong if pkt is external mbuf, pkt won't be
>> > freed because of incorrect refcnt, the result is
>> > application can't allocate mbuf from mempool because
>> > mbufs in
Konstantin, thank you so much for comments, my replies inline, please check
them.
At 2020-10-22 21:16:43, "Ananyev, Konstantin"
wrote:
>
>>
>> rte_gso_segment decreased refcnt of pkt by one, but
>> it is wrong if pkt is external mbuf, pkt won't be
>> freed because of incorrect refcnt, the resul
From: Yi Yang
rte_gso_segment decreased refcnt of pkt by one, but
it is wrong if pkt is external mbuf, pkt won't be
freed because of incorrect refcnt, the result is
application can't allocate mbuf from mempool because
mbufs in mempool are run out of.
One correct way is application should call
rt
; attach to
>
>
>
> From: yang_y_yi
> Sent: Monday, October 19, 2020 7:45 AM
> To: Hu, Jiayu
> Cc: Ananyev, Konstantin ; dev@dpdk.org;
> olivier.m...@6wind.com; tho...@monjalon.net;
> yangy...@inspur.com
> Subject: Re:RE: Re:RE: [PATCH] gso: fix free issue of m
At 2020-10-19 11:17:48, "Hu, Jiayu" wrote:
>
>
>> -Original Message-
>> From: Ananyev, Konstantin
>> Sent: Friday, October 16, 2020 4:31 PM
>> To: Hu, Jiayu ; yang_y_yi
>> Cc: dev@dpdk.org; olivier.m...@6wind.com; tho...@monjalon.net;
>&g
At 2020-10-16 08:53:00, "Hu, Jiayu" wrote:
>
>
>> -Original Message-
>> From: Ananyev, Konstantin
>> Sent: Friday, October 16, 2020 12:16 AM
>> To: Hu, Jiayu ; yang_y_yi
>> Cc: dev@dpdk.org; olivier.m...@6wind.com; tho...@monjalon.net
At 2020-10-16 00:16:03, "Ananyev, Konstantin"
wrote:
>
>
>>
>> > -Original Message-
>> > From: Ananyev, Konstantin
>> > Sent: Wednesday, October 14, 2020 8:06 PM
>> > To: yang_y_yi ; Hu, Jiayu
>> > Cc: dev@dpdk.org; ol
Got it, thanks a lot.
At 2020-10-14 21:55:25, "Olivier Matz" wrote:
>Hi,
>
>On Sat, Oct 10, 2020 at 09:49:35AM +0800, yang_y_yi wrote:
>> Olivier, thank you so much for helping figure out this, it does work
>> as the code you changed, so we
I think it isn't a good idea to free it in rte_gso_segment, maybe application
will continue to use this pkt for other purpose, rte_gso_segment can't make
decision for application without any notice, it is better to return this
decision right backt to application.
At 2020-10-
From: Yi Yang
rte_gso_segment decreased refcnt of pkt by one, but
it is wrong if pkt is external mbuf, pkt won't be
freed because of incorrect refcnt, the result is
application can't allocate mbuf from mempool because
mbufs in mempool are run out of.
One correct way is application should call
rt
Matz" wrote:
>Hi,
>
>On Fri, Oct 09, 2020 at 05:51:23PM +0800, yang_y_yi wrote:
>> Olivier, thank you so much for your reply, your patch post for vhost help me
>> understand your concern better, I totally agree. For GSO case, let me show
>>
:21, "Olivier Matz" wrote:
>Hi,
>
>On Sun, Sep 27, 2020 at 01:55:21PM +0800, yang_y_yi wrote:
>> Per GSO requirement, this is a must-have change, Jiayu, can you help review
>> this series?
>
>I can't ack this patch until I have a simple and clear test case (
Thanks Oliver for posting this patch, it clearly explain his concern, I totally
agree this change. I tested it by OVS DPDK, it works well.
At 2020-10-07 20:53:18, "Olivier Matz" wrote:
>In virtio_dev_extbuf_alloc(), the shinfo structure used to store
>the reference counter and the free callback
Tested-by: Yi Yang
At 2020-10-07 20:53:18, "Olivier Matz" wrote:
>In virtio_dev_extbuf_alloc(), the shinfo structure used to store
>the reference counter and the free callback of the external buffer
>is by default stored inside the mbuf data.
>
>This is wrong because the mbuf
Thanks for reminder, marked as Superseded.
At 2020-10-09 16:14:15, "David Marchand" wrote:
>On Fri, Oct 9, 2020 at 10:13 AM yang_y_yi wrote:
>>
>> Please ignore this one, it indeed has been there.
>
>Please mark it accordingly in patchwork.
>Thank you.
>
>
>--
>David Marchand
Please ignore this one, it indeed has been there.
At 2020-10-09 15:40:59, yang_y...@163.com wrote:
>From: Yi Yang
>
>Release 20.11 added UDP/IPv4 and VXLAN UDP/IPv4 support
>for GRO, so update rel_notes to reflect these changes.
>
>Signed-off-by: Yi Yang
>Acked-by: Jiayu Hu
>---
> doc/guides/re
rep "\.rst" 0002-gro-add-VXLAN-UDP-IPv4-GRO-support.patch
At 2020-10-09 15:47:49, "yang_y_yi" wrote:
>Thomas, sorry for confusion, previous two merges did include changes against
>doc/guides/prog_guide/generic_receive_offload_lib.rst, but
>doc/guides/rel_notes/release
https://patches.dpdk.org/patch/80105/, thanks a lot.
At 2020-10-09 14:48:19, "Thomas Monjalon" wrote:
>09/10/2020 08:34, yang_y_yi:
>> Thomas, only this one of this series hasn't yet been merged, maybe you
>> missed it, also please help merge it, thanks a lot.
>
>No I did no
From: Yi Yang
Release 20.11 added UDP/IPv4 and VXLAN UDP/IPv4 support
for GRO, so update rel_notes to reflect these changes.
Signed-off-by: Yi Yang
Acked-by: Jiayu Hu
---
doc/guides/rel_notes/release_20_11.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/doc/guides/rel_notes/rele
Thomas, only this one of this series hasn't yet been merged, maybe you missed
it, also please help merge it, thanks a lot.
At 2020-09-27 12:56:54, "Hu, Jiayu" wrote:
>Acked-by: Jiayu Hu
>
>> -Original Message-
>> From: yang_y...@163.com
>> Sent: Thursday, September 24, 2020 4:58 PM
>
Jiayu, also please help review this GSO patch, thanks a lot.
At 2020-07-01 14:46:43, yang_y...@163.com wrote:
>From: Yi Yang
>
>Many NICs can't offload VXLAN UFO, so it is very important
>to do VXLAN UDP GSO by software to improve VM-to-VM UDP
>performance, especially for the ca
31:19, "yang_y_yi" wrote:
At 2020-08-03 20:34:25, "Olivier Matz" wrote:
>On Mon, Aug 03, 2020 at 05:42:13PM +0800, yang_y_yi wrote:
>> At 2020-08-03 16:11:39, "Olivier Matz" wrote:
>> >On Mon, Aug 03, 2020 at 09:26:40AM +0800, yang_y_yi wrote:
>>
Ok, thanks Jiayu, but I don't know before which "}" whitespace should be
inserted, can you paste your check report here?
BTW, I used chekpatch.pl in Linux 5.5.9, it doesn't report this,I also tried
checkpatch.pl in Linus kernel git tree, the same result, so out of curiosity,
can you send me yo
From: Yi Yang
In case that UFO or GSO is enabled, GRO is very necessary,
especially for UDP, it is more so. Many NICs can't support
VXLAN UDP UFO/USO and VLAN UFO/USO, so UDP performance
improvement depends on GSO and GRO to a great extent.
This patch series added VLAN UDP/IPv4 GRO and VXLAN UDP
From: Yi Yang
UDP/IPv4 GRO can help improve VM-to-VM UDP performance
when UFO or GSO is enabled in VM, GRO must be supported
if UFO or GSO is enabled, otherwise, performance can't
get big improvement if only GSO is there.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM UD
From: Yi Yang
VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP
performance when UFO or GSO is enabled in VM, GRO
must be supported if UFO or GSO is enabled,
otherwise, performance can't get big improvement
if only GSO is there.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to
From: Yi Yang
Release 20.11 added UDP/IPv4 and VXLAN UDP/IPv4 support
for GRO, so update prog_guide and rel_notes to reflect
these changes.
Signed-off-by: Yi Yang
---
doc/guides/prog_guide/generic_receive_offload_lib.rst | 6 +++---
doc/guides/rel_notes/release_20_11.rst| 6 +++
9-23 10:43:03, "Jiayu Hu" wrote:
>On Wed, Sep 23, 2020 at 10:28:00AM +0800, yang_y_yi wrote:
>> Thanks Jiayu, do you mean not comparing timestamp and flush all the packets
>> in
>> a flow as I showed code, right? If so, we shouldn't provide argument
>&g
esult may be you
can't reassemble out any original UDP packet because every UDP fragments will
be flushed very soon, no chance to reassemble.
At 2020-09-23 10:15:12, "Jiayu Hu" wrote:
>On Tue, Sep 22, 2020 at 03:38:29PM +0800, yang_y_yi wrote:
>> The problem is timestamp o
46, "Jiayu Hu" wrote:
>On Tue, Sep 22, 2020 at 02:23:39PM +0800, yang_y_yi wrote:
>> Not a question, in next flush, they will be flushed, we have to check
>> timestamp
>> in the first time unless we don't strictly follow this time limitation.
>
>who wil
ts
will not be checked. This is what I want to say.
From: yang_y_yi
Sent: Tuesday, September 22, 2020 9:44 AM
To: Hu, Jiayu
Cc: dev@dpdk.org; tho...@monjalon.net; yangy...@inspur.com
Subject: Re:Re: [dpdk-dev] [PATCH v6 2/3] gro: add VXLAN UDP/IPv4 GRO support
Importance: High
BTW, start_
're saying), they can be
merged, so it isn't the case you're saying.
At 2020-09-22 11:01:26, "Jiayu Hu" wrote:
>On Tue, Sep 22, 2020 at 09:29:38AM +0800, yang_y_yi wrote:
>> Thanks Jiayu, I have fixed other comments except this one:
>>
>>
>>
.
At 2020-09-22 09:29:38, "yang_y_yi" wrote:
>Thanks Jiayu, I have fixed other comments except this one:
>
>
>
>>The items of a flow are ordered by frag_oft, and start_time
>>of these items is not always in ascending order. Therefore,
>>you cannot
Thanks Jiayu, I have fixed other comments except this one:
>The items of a flow are ordered by frag_oft, and start_time
>of these items is not always in ascending order. Therefore,
>you cannot skip checking the items after the item whose
>start_time is greater than flush_timestamp. This issue al
From: Yi Yang
VXLAN UDP/IPv4 GRO can help improve VM-to-VM UDP
performance when UFO or GSO is enabled in VM, GRO
must be supported if UFO or GSO is enabled,
otherwise, performance can't get big improvement
if only GSO is there.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to
From: Yi Yang
Release 20.11 added UDP/IPv4 and VXLAN UDP/IPv4 support
for GRO, so update prog_guide and rel_notes to reflect
these changes.
Signed-off-by: Yi Yang
---
doc/guides/prog_guide/generic_receive_offload_lib.rst | 6 +++---
doc/guides/rel_notes/release_20_11.rst| 6 +++
From: Yi Yang
UDP/IPv4 GRO can help improve VM-to-VM UDP performance
when UFO or GSO is enabled in VM, GRO must be supported
if UFO or GSO is enabled, otherwise, performance can't
get big improvement if only GSO is there.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM UD
From: Yi Yang
In case that UFO or GSO is enabled, GRO is very necessary,
especially for UDP, it is more so. Many NICs can't support
VXLAN UDP UFO/USO and VLAN UFO/USO, so UDP performance
improvement depends on GSO and GRO to a great extent.
This patch series added VLAN UDP/IPv4 GRO and VXLAN UDP
ause it is
meaningless
for reassembly in the ovs case you mentioned, rather than it’s out-of-order.
You can
give the ovs example in the commit log, and it’s easier to understand the code
IMO.
Thanks,
Jiayu
From: yang_y_yi
Sent: Wednesday, September 16, 2020 11:06 AM
To: Hu, Jiayu
Cc: yangy...@
From: Yi Yang
Fragment offset of IPv4 header is measured in units of
8 bytes. Fragment offset of UDP fragments will be wrong
after GSO if pyld_unit_size isn't multiple of 8. Say
pyld_unit_size is 1500, fragment offset of the second
UDP fragment will be 187 (i.e. 1500 / 8), which means 1496,
and i
No, next_proto_id of inner IP header can clearly identify it is a UDP packet
even if it is a no-udp-header ip fragment.
At 2020-09-16 10:54:24, "Jiayu Hu" wrote:
>On Mon, Sep 14, 2020 at 05:14:59PM +0800, yang_y_yi wrote:
>>
>> Jiayu, VM to VM cas
r IP ID when DF is 0.
Can you give more explanation?
From: yang_y_yi
Sent: Monday, September 14, 2020 4:27 PM
To: Hu, Jiayu
Cc: tho...@monjalon.net; yangy...@inspur.com; dev@dpdk.org
Subject: Re:Re: Re: [PATCH v5 2/2] gro: add VXLAN UDP GRO support
Importance: High
For outer_ip_id, there is
BTW, you need to update the programmer guide
>doc/guides/prog_guide/generic_receive_offload_lib.rst and
>release note doc/guides/rel_notes/release_20_11.rst.
>
>Thanks,
>Jiayu
>
>On Mon, Sep 14, 2020 at 10:13:44AM +0800, yang_y_yi wrote:
>> Jiayu, thank you so much, please c
0_11.rst.
>
>Thanks,
>Jiayu
>
>On Mon, Sep 14, 2020 at 10:13:44AM +0800, yang_y_yi wrote:
>> Jiayu, thank you so much, please check my replies for some of your comments,
>> here is incremental patch. I built it by meson this time :-)
>>
>> diff --git a/lib/li
Thanks Jiayu, I have sent out v5.
At 2020-09-10 10:47:43, "Hu, Jiayu" wrote:
No more comments on this patch.
Thanks,
Jiayu
From: yang_y_yi
Sent: Wednesday, September 9, 2020 5:00 PM
To: Hu, Jiayu
Cc: tho...@monjalon.net; dev@dpdk.org; yangy...@inspur.com
Subject: Re:Re:
From: Yi Yang
VXLAN UDP GRO can help improve VM-to-VM UDP performance
when VM is enabled UFO or GSO, GRO must be supported if
GSO or UFO is enabled, otherwise, performance gain will
be hurt.
With this enabled in DPDK, OVS DPDK can leverage it to
improve VM-to-VM UDP performance, this will make s
From: Yi Yang
UDP GRO can help improve VM-to-VM UDP performance when
VM is enabled UFO or GSO, GRO must be supported if GSO
or UFO is enabled, otherwise, performance gain will be
hurt.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM UDP performance, this will make
sure IP
From: Yi Yang
In case that UFO or GSO is enabled, GRO is very necessary,
especially for UDP, it is more so. Many NICs can't support
VXLAN UDP UFO/USO and VLAN UFO/USO, so UDP performance
improvement depends on GSO and GRO to a great extent.
This patch series added VLAN UDP GRO and VXLAN UDP GRO
* Check if two UDP/IPv4 packets are neighbors.
*/
static inline int
-udp_check_neighbor(struct gro_udp4_item *item,
+udp4_check_neighbor(struct gro_udp4_item *item,
uint16_t frag_offset,
uint16_t ip_dl,
uint16_t l2_offset)
At 2020-09-09 15:25:10, &quo
At 2020-09-08 10:05:16, "Jiayu Hu" wrote:
>Some comments are inline.
Thanks, replies inline.
>
>Thanks,
>Jiayu
>
>On Fri, Sep 04, 2020 at 04:37:39PM +0800, yang_y...@163.com wrote:
>> From: Yi Yang
>>
>> UDP GRO can help improve VM-to-VM UDP performance when
>> VM is enabled UFO or GSO, GRO
From: Yi Yang
UDP GRO can help improve VM-to-VM UDP performance when
VM is enabled UFO or GSO, GRO must be supported if GSO
or UFO is enabled, otherwise, performance gain will be
hurt.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM UDP performance, this will make
sure IP
From: Yi Yang
In case that UFO or GSO is enabled, GRO is very necessary,
especially for UDP, it is more so. Many NICs can't support
VXLAN UDP UFO/USO and VLAN UFO/USO, so UDP performance
improvement depends on GSO and GRO to a great extent.
This patch series added VLAN UDP GRO and VXLAN UDP GRO
From: Yi Yang
VXLAN UDP GRO can help improve VM-to-VM UDP performance
when VM is enabled UFO or GSO, GRO must be supported if
GSO or UFO is enabled, otherwise, performance gain will
be hurt.
With this enabled in DPDK, OVS DPDK can leverage it to
improve VM-to-VM UDP performance, this will make s
At 2020-09-03 15:42:48, "Hu, Jiayu" wrote:
>Hi Yi,
>
>Some comments are inline.
>
>In addition, have you tested UDP GRO function and measure performance?
Yes, I tested GRO and GSO together. The test case is VM sends 8K UDP packet by
vhostuserclient, OVS DPDK GSOed it as size 1450 packets, send t
. Either user or rte_gro_rx_prepare()
provides
correct l2_len etc. value.
Thanks,
Jiayu
From: yang_y_yi
Sent: Wednesday, September 2, 2020 1:58 PM
To: Hu, Jiayu
Cc: dev@dpdk.org; tho...@monjalon.net; yangy...@inspur.com
Subject: Re:RE: Re:Re: [dpdk-dev] [PATCH] gro: add UDP GRO and VXLAN
From: Yi Yang
VXLAN UDP GRO can help improve VM-to-VM UDP performance
when VM is enabled UFO or GSO, GRO must be supported if
GSO or UFO is enabled, otherwise, performance gain will
be hurt.
With this enabled in DPDK, OVS DPDK can leverage it to
improve VM-to-VM UDP performance, this will make s
From: Yi Yang
In case that UFO or GSO is enabled, GRO is very necessary,
especially for UDP, it is more so. Many NICs can't support
VXLAN UDP UFO/USO and VLAN UFO/USO, so UDP performance
improvement depends on GSO and GRO to a great extent.
This patch series added VLAN UDP GRO and VXLAN UDP GRO
From: Yi Yang
UDP GRO can help improve VM-to-VM UDP performance when
VM is enabled UFO or GSO, GRO must be supported if GSO
or UFO is enabled, otherwise, performance gain will be
hurt.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM UDP performance, this will make
sure IP
Packet type is checked by mbuf->packet_type field, and input
packets should provide correct packet_type value. TCP GRO
only process TCP packets whose header length is between
20 and 60 bytes. So we check l4_len.
From: yang_y_yi
Sent: Tuesday, September 1, 2020 4:43 PM
To: Hu, Jiayu
Cc: dev@dpd
From: Yi Yang
In case that UFO or GSO is enabled, GRO is very necessary,
especially for UDP, it is more so. Many NICs can't support
VXLAN UDP UFO/USO and VLAN UFO/USO, so UDP performance
improvement depends on GSO and GRO to a great extent.
This patch series added VLAN UDP GRO and VXLAN UDP GRO
From: Yi Yang
UDP GRO can help improve VM-to-VM UDP performance when
VM is enabled UFO or GSO, GRO must be supported if GSO
or UFO is enabled, otherwise, performance gain will be
hurt.
With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM UDP performance, this will make
sure IP
From: Yi Yang
VXLAN UDP GRO can help improve VM-to-VM UDP performance
when VM is enabled UFO or GSO, GRO must be supported if
GSO or UFO is enabled, otherwise, performance gain will
be hurt.
With this enabled in DPDK, OVS DPDK can leverage it to
improve VM-to-VM UDP performance, this will make s
Jiayu, BTW, after I check it again, I think udp header length check is
necessary, it is actually a sanity check io order to ensure it is indeed a udp
packet, gro_tcp4.c did same thing.
At 2020-09-01 14:10:41, "yang_y_yi" wrote:
>At 2020-09-01 12:27:29, "Hu, Jiayu" wr
At 2020-09-01 12:27:29, "Hu, Jiayu" wrote:
>Hi Yi,
>
>This patch supports UDP and VxLAN/UDP, but both are in one patch.
>It's too large, and please split it into small patches.
Jiayu, thank you so much for your great review , I'll send v2 to split it into
two patches and fix your comments. Detai
From: Yi Yang
IP fragment offset in IP header must be multiple of
8, if pyld_unit_size isn't multiple of 8, IP total
length will be wrong after reassemble, IP payload
also will be wrong because some data is lost on
reassembling.
This has been verified in OVS DPDK by VLAN TSO iperf3
UDP case.
Fi
At 2020-08-03 20:34:25, "Olivier Matz" wrote:
>On Mon, Aug 03, 2020 at 05:42:13PM +0800, yang_y_yi wrote:
>> At 2020-08-03 16:11:39, "Olivier Matz" wrote:
>> >On Mon, Aug 03, 2020 at 09:26:40AM +0800, yang_y_yi wrote:
>> >> At 202
At 2020-08-03 16:11:39, "Olivier Matz" wrote:
>On Mon, Aug 03, 2020 at 09:26:40AM +0800, yang_y_yi wrote:
>> At 2020-08-03 04:29:07, "Olivier Matz" wrote:
>> >Hi,
>> >
>> >On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote:
>>
At 2020-08-03 04:45:12, "Olivier Matz" wrote:
>On Sun, Aug 02, 2020 at 10:29:07PM +0200, Olivier Matz wrote:
>> Hi,
>>
>> On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote:
>> >
>> >
>> > At 2020-07-31 23:15:43, "Olivier
At 2020-08-03 04:29:07, "Olivier Matz" wrote:
>Hi,
>
>On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote:
>>
>>
>> At 2020-07-31 23:15:43, "Olivier Matz" wrote:
>> >Hi,
>> >
>> >On Thu, Jul 30, 2020 at 08:08:59P
At 2020-07-31 23:15:43, "Olivier Matz" wrote:
>Hi,
>
>On Thu, Jul 30, 2020 at 08:08:59PM +0800, yang_y...@163.com wrote:
>> From: Yi Yang
>>
>> In GSO case, segmented mbufs are attached to original
>> mbuf which can't be freed when it is external. The issue
>> is free_cb doesn't know original
From: Yi Yang
typedef rte_mbuf_extbuf_free_callback_t will be deprecated
in 20.08 release.
Signed-off-by: Yi Yang
---
doc/guides/rel_notes/deprecation.rst | 8
1 file changed, 8 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
in
Unfortunately, git send-email in windows can't work with -cc-cmd, I just tried
it but maintainers weren't added to cc list. Here is my get-maintainer.sh.
Anybody knows why it can't work.
$ ./get-maintainer.sh dpdk-patches/-cover-letter.patch
yangyi01@yangyi0100 MINGW64 ~
$ ./get-maintainer
From: Yi Yang
New free_cb interface can help fix original external
mbuf free issue in GSO case, it still can be compatible
with normal non-GSO case. dpdkvhostuser port can work
both in GSO case and in non-GSO case by this fix.
Signed-off-by: Yi Yang
---
lib/librte_vhost/virtio_net.c | 22 +
From: Yi Yang
It is impossible to fix external mbuf free issue in GSO case,
the issue is GSO case only can free buffer in external mbuf
but can't free this external mbuf because this is done by free_cb,
in order to fix it, free_cb interface has to been changed to
adapt to GSO case, this patch ser
From: Yi Yang
In GSO case, segmented mbufs are attached to original
mbuf which can't be freed when it is external. The issue
is free_cb doesn't know original mbuf and doesn't free
it when refcnt of shinfo is 0.
Original mbuf can be freed by rte_pktmbuf_free segmented
mbufs or by rte_pktmbuf_free
1 - 100 of 109 matches
Mail list logo
