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]
Message-ID: <20240913150649.GB14069@linux.alibaba.com>
Date: Fri, 13 Sep 2024 23:06:49 +0800
From: Dust Li <dust.li@...ux.alibaba.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Philo Lu <lulie@...ux.alibaba.com>, netdev@...r.kernel.org,
	willemdebruijn.kernel@...il.com, davem@...emloft.net,
	kuba@...nel.org, pabeni@...hat.com, dsahern@...nel.org,
	antony.antony@...unet.com, steffen.klassert@...unet.com,
	linux-kernel@...r.kernel.org, jakub@...udflare.com
Subject: Re: [RFC PATCH net-next] net/udp: Add 4-tuple hash for connected
 socket

On 2024-09-13 16:39:33, Eric Dumazet wrote:
>On Fri, Sep 13, 2024 at 4:22 PM Dust Li <dust.li@...ux.alibaba.com> wrote:
>>
>> On 2024-09-13 13:49:03, Eric Dumazet wrote:
>> >On Fri, Sep 13, 2024 at 12:09 PM Philo Lu <lulie@...ux.alibaba.com> wrote:
>> >>
>> >> This RFC patch introduces 4-tuple hash for connected udp sockets, to
>> >> make udp lookup faster. It is a tentative proposal and any comment is
>> >> welcome.
>> >>
>> >> Currently, the udp_table has two hash table, the port hash and portaddr
>> >> hash. But for UDP server, all sockets have the same local port and addr,
>> >> so they are all on the same hash slot within a reuseport group. And the
>> >> target sock is selected by scoring.
>> >>
>> >> In some applications, the UDP server uses connect() for each incoming
>> >> client, and then the socket (fd) is used exclusively by the client. In
>> >> such scenarios, current scoring method can be ineffcient with a large
>> >> number of connections, resulting in high softirq overhead.
>> >>
>> >> To solve the problem, a 4-tuple hash list is added to udp_table, and is
>> >> updated when calling connect(). Then __udp4_lib_lookup() firstly
>> >> searches the 4-tuple hash list, and return directly if success. A new
>> >> sockopt UDP_HASH4 is added to enable it. So the usage is:
>> >> 1. socket()
>> >> 2. bind()
>> >> 3. setsockopt(UDP_HASH4)
>> >> 4. connect()
>> >>
>> >> AFAICT the patch (if useful) can be further improved by:
>> >> (a) Support disable with sockopt UDP_HASH4. Now it cannot be disabled
>> >> once turned on until the socket closed.
>> >> (b) Better interact with hash2/reuseport. Now hash4 hardly affects other
>> >> mechanisms, but maintaining sockets in both hash4 and hash2 lists seems
>> >> unnecessary.
>> >> (c) Support early demux and ipv6.
>> >>
>> >> Signed-off-by: Philo Lu <lulie@...ux.alibaba.com>
>> >
>> >Adding a 4-tuple hash for UDP has been discussed in the past.
>>
>> Thanks for the information! we don't know the history.
>>
>> >
>> >Main issue is that this is adding one cache line miss per incoming packet.
>>
>> What about adding something like refcnt in 'struct udp_hslot' ?
>> if someone enabled uhash4 on the port, we increase the refcnt.
>> Then we can check if that port have uhash4 enabled. If it's zero,
>> we can just bypass the uhash4 lookup process and goto the current
>> udp4_lib_lookup2().
>>
>
>Reading anything (thus a refcnt) in 'struct udp_hslot' will need the
>same cache line miss.

hslot2->head in 'struct udp_hslot' will be read right away in
udp4_lib_lookup2() in any case, it's just a few instructions
later(about 20). So I think cache miss should not be a problem
in this case.

>
>Note that udp_hslot already has a 'count' field

Yes, but that's for uhash/uhash2. I'm thinking of adding something
to indicate that uhash4 was enabled on this port. So we can avoid
the extra memory footprint on some cold memory. Maybe 'struct udp_hslot'
is not a good place.

Best regards,
Dust


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ