netdev - Re: epoll, missed opportunity?

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] [day] [month] [year] [list]

Message-ID: <CACKT+Ao8OLchwUHPn-PKebx3pi2opMg9LH+SGaj+xdghfbSVag@mail.gmail.com>
Date:	Sat, 19 Sep 2015 09:51:22 -0600
From:	Jonathan Marler <johnnymarler@...il.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: epoll, missed opportunity?

Wow how did I miss that?! This is perfect though, there is a context
pointer!  Finally my dream of a perfect polling interface exists in
linux.  Thanks so much for the quick response.

On Sat, Sep 19, 2015 at 9:46 AM, Tom Herbert <tom@...bertland.com> wrote:
> On Sat, Sep 19, 2015 at 8:30 AM, Jonathan Marler <johnnymarler@...il.com> wrote:
>> The data field holds the file descriptor you are waiting on, it has to
>> be the file descriptor, otherwise, how would the kernel know which
>> file descriptor you are trying to wait on?
>>
> fd is the third argument in epoll_ctl.
>
> int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
>
>> On Sat, Sep 19, 2015 at 9:21 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>>> On Fri, 2015-09-18 at 22:51 -0600, Jonathan Marler wrote:
>>>> I'm curious why there wasn't another field added to the epoll_event
>>>> struct for the application to store the descriptor's context. Any
>>>> useful multi-plexing application will have a context that will need to
>>>> be retrieved every time a descriptor needs to be serviced. Since the
>>>> epoll api has no way of storing this context, it has to be looked up
>>>> using the descriptor, which will take more time/memory as the number
>>>> of descriptors increase. The memory saved from omitting this context
>>>> can't be worth it since you'll have to allocate the memory in the
>>>> application anyway, plus you're now adding the extra lookup.
>>>>
>>>> This "lookup" problem has always existed in multi-plexed applications.
>>>> It was impossible to fix with older polling interfaces, however, since
>>>> epoll is stateful, it provides an opportunity to fix this problem by
>>>> storing the descriptor context in epoll's "state". What was the reason
>>>> for not doing this?  Was it an oversight or am I missing something?
>>>
>>>
>>> typedef union epoll_data
>>> {
>>>   void *ptr;
>>>   int fd;
>>>   uint32_t u32;
>>>   uint64_t u64;
>>> } epoll_data_t;
>>>
>>> struct epoll_event
>>> {
>>>   uint32_t events;      /* Epoll events */
>>>   epoll_data_t data;    /* User data variable */
>>> } __EPOLL_PACKED;
>>>
>>>
>>>
>>> Application is free to use whatever is needed in poll_data_t
>>>
>>> You can store a pointer to your own data (ptr)
>>> Or a 32 bit cookie (u32)
>>> Or a 64 bit cookie (u64)
>>>
>>> (But is an union, you have to pick one of them)
>>>
>>> Nothing forces you to use 'fd', kernel does not care.
>>>
>>>
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html