th the
introduction of BPF itself, should we expect a performance drop in
these applications?
Best Regards,
Tolga Ceylan
t; merge window (given that it's not a fix per-se) ? If so I'll resubmit
>> >> > later.
>> >>
>> >> I need to check with Craig Gallek, because he was about to upstream a
>> >> change to make SO_REUSEPORT more scalable & sexy (like having an [e]BPF
>> >> filter to perform the selection in an array of sockets)
>> >
Hi All,
I apologize for not properly following up on this. I had the
impression that we did not want to merge my original patch and then I
also noticed that it fails to keep the hash consistent. Recently, I
read the follow ups on it as well as Willy's patch/proposals.
Is there any update on Willy's SO_REUSEPORT patch? IMHO, it solves the
problem and it is simpler than adding new sock option.
Best Regards,
Tolga Ceylan
On Sat, Sep 26, 2015 at 6:44 PM, Aaron Conole wrote:
> Greetings.
>
> Tolga Ceylan writes:
>> +#define SO_REUSEPORT_LISTEN_OFF 51
>> +
> For all of these, I think the space should be tab.
>
>> unsigned char skc_reuseport:1;
>>+ unsigne
On Sat, Sep 26, 2015 at 6:04 PM, Eric Dumazet wrote:
>
> What about listen(fd, 0) ?
>
> Not sure we need to add a new socket option.
>
> It makes sense to extend reuseport logic to ignore listeners with a 0
> backlog (if not already done, I did not check)
>
>
Just checked this and no listen(fd, 0
.
Signed-off-by: Tolga Ceylan
---
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/avr32/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h| 2 ++
arch/m32r/include/uapi/asm/socket.h| 2 ++
arch/mips/include/uapi/asm
