lkml.org 
[lkml]   [2019]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] eventfd new tag EFD_VPOLL: generate epoll events
On 2019-05-31 12:45, Renzo Davoli wrote:
> HI Roman,
>
> On Fri, May 31, 2019 at 11:34:08AM +0200, Roman Penyaev wrote:
>> On 2019-05-27 15:36, Renzo Davoli wrote:
>> > Unfortunately this approach cannot be applied to
>> > poll/select/ppoll/pselect/epoll.
>>
>> If you have to override other systemcalls, what is the problem to
>> override
>> poll family? It will add, let's say, 50 extra code lines complexity
>> to your
>> userspace code. All you need is to be woken up by *any* event and
>> check
>> one mask variable, in order to understand what you need to do: read or
>> write,
>> basically exactly what you do in your eventfd modification, but only
>> in
>> userspace.
>
> This approach would not scale. If I want to use both a (user-space)
> network stack
> and a (emulated) device (or more stacks and devices) which
> (overridden) poll would I use?
>
> The poll of the first stack is not able to to deal with the third
> device.

Since each such a stack has a set of read/write/etc functions you always
can extend you stack with another call which returns you event mask,
specifying what exactly you have to do, e.g.:

nfds = epoll_wait(epollfd, events, MAX_EVENTS, -1);
for (n = 0; n < nfds; ++n) {
struct sock *sock;

sock = events[n].data.ptr;
events = sock->get_events(sock, &events[n]);

if (events & EPOLLIN)
sock->read(sock);
if (events & EPOLLOUT)
sock->write(sock);
}


With such a virtual table you can mix all userspace stacks and even
with normal sockets, for which 'get_events' function can be declared as

static poll_t kernel_sock_get_events(struct sock *sock, struct
epoll_event *ev)
{
return ev->events;
}

Do I miss something?


>> > > Why can it not be less than 64?
>> > This is the imeplementation of 'write'. The 64 bits include the
>> > 'command'
>> > EFD_VPOLL_ADDEVENTS, EFD_VPOLL_DELEVENTS or EFD_VPOLL_MODEVENTS (in the
>> > most
>> > significant 32 bits) and the set of events (in the lowest 32 bits).
>>
>> Do you really need add/del/mod semantics? Userspace still has to keep
>> mask
>> somewhere, so you can have one simple command, which does:
>> ctx->count = events;
>> in kernel, so no masks and this games with bits are needed. That will
>> simplify API.
>
> It is true, at the price to have more complex code in user space.
> Other system calls could have beeen implemented as "set the value",
> instead there are
> ADD/DEL modification flags.
> I mean for example sigprocmask (SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK),
> or even epoll_ctl.
> While poll requires the program to keep the struct pollfd array stored
> somewhere,
> epoll is more powerful and flexible as different file descriptors can
> be added
> and deleted by different modules/components.
>
> If I have two threads implementing the send and receive path of a
> socket in a user-space

Eventually you come up with such a lock to protect your tcp or whatever
state machine. Or you have a real example where read and write paths
can work completely independently?

--
Roman

\
 
 \ /
  Last update: 2019-05-31 13:49    [W:0.090 / U:1.416 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site