On Wed, Nov 28, 2018 at 7:09 PM Jana Iyengar <jri.i...@gmail.com> wrote: > > > On Wed, Nov 28, 2018 at 6:19 PM Eric Dumazet <eduma...@google.com> wrote: >> >> On Wed, Nov 28, 2018 at 5:57 PM Christoph Paasch <cpaa...@apple.com> wrote: >> > >> > 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. > > >> 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 ... > > >> Also you add another cache line miss in UDP lookup to access >> udp_sk()->wait_for_connect. >> >> 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.
