Hello,

On 28/11/18 - 19:15:12, Eric Dumazet wrote:

On Wed, Nov 28, 2018 at 7:09 PM Jana Iyengar [off-list ref] wrote:

quoted

On Wed, Nov 28, 2018 at 6:19 PM Eric Dumazet [off-list ref] wrote:

quoted

On Wed, Nov 28, 2018 at 5:57 PM Christoph Paasch [off-list ref] wrote:

quoted

There are use-cases where a host wants to use a UDP socket with a
specific 4-tuple. The way to do this is to bind() and then connect() the
socket. However, after the bind(), the socket starts receiving data even
if it does not match the intended 4-tuple. That is because after the
bind() UDP-socket will match in the lookup for all incoming UDP-traffic
that has the specific IP/port.

This patch prevents any incoming traffic until the connect() system-call
is called whenever the app sets the UDP socket-option
UDP_WAIT_FOR_CONNECT.

Please do not add something that could mislead applications writers to
think UDP stack can scale.

quoted

UDP stack does not have a full hash on 4-tuples, it means that
incoming traffic on a 'shared port' has
to scan a list of XXX sockets to find the best match ...

quoted

Also you add another cache line miss in UDP lookup to access
udp_sk()->wait_for_connect.

Fair enough. We could add the socket later to the hash (see below).

quoted

quoted

recvfrom() can be used to filter whatever frame that came before the connect()

I don't think I understand that argument -- connect() is supported for UDP sockets, and UDP sockets are being used for serving QUIC traffic. Are you suggesting that connect() never be used?

If the source port is not shared, Christoph patch is not needed.

If it is shared, then a whole can of worm is opened.

Trying to hack UDP stack while it is not fully 4-tuple ready is not
going to fly.

Indeed, the UDP-stack is not fully 4-tuple ready.


What are your thoughts on getting it there?

Should be doable by simply using a similar approach as TCP, no? Any caveats
you see with that?

Then, when one sets the "wait-for-connect"-flag we would add the socket to
the hash-table only at connect()-time also addressing the cache-line miss
you mentioned above.


Thanks,
Christoph