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 wrote:
> On Sat, Sep 19, 2015 at 8:30 AM, Jonathan Marler
> 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 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 majord...@vger.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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: epoll, missed opportunity?
On Sat, Sep 19, 2015 at 8:30 AM, Jonathan Marler 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 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 majord...@vger.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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: epoll, missed opportunity?
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?
On Sat, Sep 19, 2015 at 9:21 AM, Eric Dumazet 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: epoll, missed opportunity?
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
epoll, missed opportunity?
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? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
