Flavio, got it, thanks a lot. By the way, about too many retransmissions issue
for veth, I did further investigation, I doubt it is also a veth-related bug on
kernel side, maybe you Redhat kernel guys can help fix it, tap interface
doesn't have this issue and it has super high performance
Use ioctl TUNSETOFFLOAD if kernel supports to enable TSO
offloading in the tap device.
Fixes: 29cf9c1b3b9c ("userspace: Add TCP Segmentation Offload support")
Reported-by: "Yi Yang (杨�D)-云服务集团"
Tested-by: William Tu
Signed-off-by: Flavio Leitner
---
lib/netdev-linux.c | 17 +
I have tried to reach you on this d...@openvswitch.org mail account severally
but I have gotten no response from you, Please get back to me at your earliest
convenience if you have received my email this time.
Sincerely,
Nelson C.
___
dev mailing
Also: I applied this to master.
On Sat, Feb 29, 2020 at 11:06:54AM -0800, Ben Pfaff wrote:
> Thanks for testing!
>
> I'm a little surprised that restarting ovs-vswitchd causes the interface
> to be deleted and recreated. That might be a bug that should be
> addressed separately.
>
> On Sat,
I applied this to master.
On Sat, Feb 29, 2020 at 10:59:37AM -0800, Ben Pfaff wrote:
> Thanks for testing.
>
> I think that the "destroy" call should be outside the braces; the simap
> does not "own" the ports, it's just an string-to-integer map that needs
> to get destroyed along with the
Thanks for testing!
I'm a little surprised that restarting ovs-vswitchd causes the interface
to be deleted and recreated. That might be a bug that should be
addressed separately.
On Sat, Feb 29, 2020 at 12:16:32AM +, Antonin Bas wrote:
> Hi Ben,
>
> Thanks for the patch. I can confirm that
Thanks for testing.
I think that the "destroy" call should be outside the braces; the simap
does not "own" the ports, it's just an string-to-integer map that needs
to get destroyed along with the ofproto.
On Sat, Feb 29, 2020 at 10:26:42AM +0800, txfh2007 wrote:
> Hi Ben:
>
> I have tried,
