lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 5 Jan 2014 21:39:38 +0200
From:	Or Gerlitz <or.gerlitz@...il.com>
To:	Or Gerlitz <ogerlitz@...lanox.com>
Cc:	Jerry Chu <hkchu@...gle.com>, Eric Dumazet <edumazet@...gle.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Yan Burman <yanb@...lanox.com>,
	Shlomo Pongratz <shlomop@...lanox.com>
Subject: Re: [PATCH V1 net-next 2/2] net: Add UDP GRO support for vxlan traffic

On Sun, Jan 5, 2014 at 5:23 PM, Or Gerlitz <ogerlitz@...lanox.com> wrote:
> Add GRO handlers for UDP, with the intent of being able to coalesce vxlan
> packets which encapsulate packets belonging to the same TCP session.
>
> The UDP GRO handler will only attempt to coalesce packets whose
> destination port is used as vxlan listening port. There are two
> issues here for which I will be happy to get feedback
>
> 1. what is the most efficient way to determine if a udp port is
> owned by the vxlan driver, e.g maybe through a bit map exported by
> the vxlan driver?

To be accurate here, V1 (this patch) still has RFC aspects -- it
suggests a solution to the above matter -- the gro udp code exports
two callbacks which are invoked by the vxlan driver to add/delete udp
listening port. The callbacks maintain an O(1) accessed array which is
beeing looked from the fast path to determine if the destination udp
port of the packet under inspection is a vxlan listening port.

> 2. how to prevent the host GRO stack from coalescing guest UDP
> packets which went through vxlan encapsulation and happen to carry
> the same udp destination port as used by the host vxlan driver..

For this one, I was thinking to add some field to struct napi_gro_cb
which will be zeroed when the gro stacks starts to work on the skb and
set once we pass udp_gro_receive, such that if we arrive again to
udp_gro_recieve and this field is set, which means the encapsulated
packet is udp one, we flush.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ