* udp v6 early demux?
@ 2015-02-10 17:14 Vlad Yasevich
2015-02-10 17:32 ` Eric Dumazet
0 siblings, 1 reply; 4+ messages in thread
From: Vlad Yasevich @ 2015-02-10 17:14 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi
While testing udpv6 lockless path, I noticed that there is no
support for udpv6 early demux? Is there a technical reason why,
or was this just something that got forgotten (kind of like
lockeless sendmsg)?
Thanks
-vlad
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: udp v6 early demux?
2015-02-10 17:14 udp v6 early demux? Vlad Yasevich
@ 2015-02-10 17:32 ` Eric Dumazet
2015-02-11 2:53 ` Vlad Yasevich
0 siblings, 1 reply; 4+ messages in thread
From: Eric Dumazet @ 2015-02-10 17:32 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev@vger.kernel.org
On Tue, 2015-02-10 at 12:14 -0500, Vlad Yasevich wrote:
> Hi
>
> While testing udpv6 lockless path, I noticed that there is no
> support for udpv6 early demux? Is there a technical reason why,
> or was this just something that got forgotten (kind of like
> lockeless sendmsg)?
If you have a use case for connected UDP ipv6 flows with performance
issues, then you might add early demux I guess.
IPv4 udp early demux has been a bit of a hack actually,
as Shawn main usage was multicast AFAIK
63c6f81cdde5 udp: ipv4: do not waste time in __udp4_lib_mcast_demux_lookup
610438b74496 udp: ipv4: fix potential use after free in udp_v4_early_demux()
f69b923a758f udp: fix a typo in __udp4_lib_mcast_demux_lookup
421b3885bf6d udp: ipv4: Add udp early demux
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: udp v6 early demux?
2015-02-10 17:32 ` Eric Dumazet
@ 2015-02-11 2:53 ` Vlad Yasevich
2015-02-11 4:57 ` Eric Dumazet
0 siblings, 1 reply; 4+ messages in thread
From: Vlad Yasevich @ 2015-02-11 2:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
On 02/10/2015 12:32 PM, Eric Dumazet wrote:
> On Tue, 2015-02-10 at 12:14 -0500, Vlad Yasevich wrote:
>> Hi
>>
>> While testing udpv6 lockless path, I noticed that there is no
>> support for udpv6 early demux? Is there a technical reason why,
>> or was this just something that got forgotten (kind of like
>> lockeless sendmsg)?
>
> If you have a use case for connected UDP ipv6 flows with performance
> issues, then you might add early demux I guess.
>
> IPv4 udp early demux has been a bit of a hack actually,
> as Shawn main usage was multicast AFAIK
>
> 63c6f81cdde5 udp: ipv4: do not waste time in __udp4_lib_mcast_demux_lookup
> 610438b74496 udp: ipv4: fix potential use after free in udp_v4_early_demux()
> f69b923a758f udp: fix a typo in __udp4_lib_mcast_demux_lookup
> 421b3885bf6d udp: ipv4: Add udp early demux
>
>
I was more wondering if we can avoid the route the lookup. It may not always be
a connected a case. If you have multiple senders and a single receiver on the
same subnet, avoiding the route lookup with early demux might help.
-vlad
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: udp v6 early demux?
2015-02-11 2:53 ` Vlad Yasevich
@ 2015-02-11 4:57 ` Eric Dumazet
0 siblings, 0 replies; 4+ messages in thread
From: Eric Dumazet @ 2015-02-11 4:57 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev@vger.kernel.org
On Tue, 2015-02-10 at 21:53 -0500, Vlad Yasevich wrote:
> I was more wondering if we can avoid the route the lookup. It may not always be
> a connected a case. If you have multiple senders and a single receiver on the
> same subnet, avoiding the route lookup with early demux might help.
Yes, but early demux requires a connected socket, sorry.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-02-11 4:57 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-10 17:14 udp v6 early demux? Vlad Yasevich
2015-02-10 17:32 ` Eric Dumazet
2015-02-11 2:53 ` Vlad Yasevich
2015-02-11 4:57 ` Eric Dumazet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).