RTNL sync or async when creating GPRS Context for STE modem.

RTNL sync or async when creating GPRS Context for STE modem.

[Sjur BRENDELAND]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

Hi Marcel.

I have finally got around to do some coding in oFono again,
and have started to look into creating CAIF Network Interface 
using RTNL, instead using socket ioctls.
 
I have started out by doing the RTNL handling async, 
i.e. registering the RTNL socket with g_io_add_watch etc.
But I'm not really happy with the code as it feels
unnecessary complex, introduces new states in gprs-context.c. etc.

So I would like to do the RTNL handling synchronous instead,
as this would reduce complexity. But I just wanted your opinion
on this before I start refactoring my code.

Do you see any issues with doing RTNL request synchronous
i.e. sending out RTM_NEWLINK request and a waiting for 
RTM_NEWLINK response followed by NLMSG_ERROR,
(or just NLMSG_ERROR if unsuccessful)?


Regards
Sjur

Re: RTNL sync or async when creating GPRS Context for STE modem.

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

Le dimanche 30 mai 2010 17:45:04 Sjur BRENDELAND, vous avez écrit :
> I have started out by doing the RTNL handling async,
> i.e. registering the RTNL socket with g_io_add_watch etc.
> But I'm not really happy with the code as it feels
> unnecessary complex, introduces new states in gprs-context.c. etc.

Using an event loop makes sense if, and only if, the process blocks as far as 
poll() is concerned. If your ioctl() calls or Netlink requests do not enter 
the kernel scheduler at any point, then the glib main loop will just slows 
things down - more code, more context switches.

As an counter example, some people believe so blindly in event loops that they 
use them to read *regular* files, and then recommend it to their friends. 
Nevermind that POSIX states that regular files are always marked ready for 
POLLIN and POLLOUT events, i.e. poll()'ing a regular file will always return 
immediately. Thus the event loop is defeated, and just constitutes useless 
code complexity and wasted CPU time. (Of course, if the same code path can 
cope with non-regular files, then using poll() might make sense, don't make me 
say what I did not.)

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis

RE: RTNL sync or async when creating GPRS Context for STE modem.

[Sjur BRENDELAND]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

Rémi Denis-Courmont wrote:
> > I have started out by doing the RTNL handling async,
> > i.e. registering the RTNL socket with g_io_add_watch etc.
> > But I'm not really happy with the code as it feels
> > unnecessary complex, introduces new states in gprs-context.c. etc.
> 
> Using an event loop makes sense if, and only if, the process blocks as
> far as poll() is concerned. If your ioctl() calls or Netlink requests 
> do not enter the kernel scheduler at any point, then the glib main
> loop will just slows things down - more code, more context switches.

Thanks Denis,
I think a synchronous implementation should be find then.

If I understand RT-Netlink correctly, creating a CAIF Network Interface should
not enter the poll() or wait in recvmsg. When sending RTNL newlink message,
the whole newlink operation should execute in the senders thread, and 
response messages be ready in the rtnl sockets receive queue when the send
operation completes. Hence read/poll should not block the thread.

Regards
/Sjur