On Mon, Dec 3, 2018 at 8:45 AM Christoph Paasch <cpaa...@apple.com> wrote: > > On 29/11/18 - 14:59:36, Eric Dumazet wrote: > > On Thu, Nov 29, 2018 at 2:47 PM Christoph Paasch <cpaa...@apple.com> wrote: > > > > > Indeed, the UDP-stack is not fully 4-tuple ready. > > > > > > > > > What are your thoughts on getting it there? > > > > This would request an additional lookup, and heavy duty servers using > > non connected sockets > > would pay the price for an extra lookup for each incoming packets. > > Indeed. > > > But I'm sure we can do it such that those servers don't pay a cost. > > E.g., with a jump-label that would only be set when one does a > "wait-for-connect" > and only these sockets end up in that 4-tuple hash-table.
That will work only for benchmarks. Typical servers have a variety of concurrent tasks. jump labels are kind of doomed with network namespaces, and we cant really enable/disable them from a non privileged application, since this slows down the whole machine. > > > DNS servers and QUIC servers would not like that, since they have better use > > of a single (unconnected) UDP socket per cpu/thread. > > I'm actually wondering, how are you doing Quic connection migration when > having a single unconnected UDP socket per CPU? That would involve quite > some cross-CPU communication, no? Maybe a small percentage of packets do need this, so we do not care. > > Except if something else is steering the different UDP-flows that belong to > the > same Quic connection to the right CPU... > > > Christoph > > > > > > > > > > > > > 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. > > > > Sure.
