rtnet-developers

[RTnet-developers] SO_TIMESTAMPNS for RTnet

[Manuel H. <man...@gm...>]

Hello!

I'm currently working on a patch for RTnet
(https://bitbucket.org/robinreal/rtnetts/overview exp branch) that
enables the user to retrieve time stamps from the driver (via
recvmsg). Currently development is not finished, there are still
bugs and I need to rewrite commit messages. Overview:

* I hooked into the rt_udp_recvmsg function to optionally add time
   stamps to the msghdr struct. The rt_socket_recv_timestamp function
   is used to actually retrieve put the time stamp into the cmsg
   buffer. This could maybe also be used for other protocols (?).

* In stack/scm.c the original put_cmsg function has been ported to
   RTDM. Currently I haven't yet implemented the put_cmsg_compat
   function.

* In rtnet_socket.h I added a member sk_flags, which could be used for
   various other functions. This is used to activate and deactivate
   passing time stamps to the user (through msghdr structure).

* CONFIG_RTNET_SO_TIMESTAMPNS can be used to control whether RTnet
   stack supports passing timestamps to user-space or not.


During implementation I ran into some problems:

* I couldn't really find out, where the "normal" Linux Kernel fixes
   the cmsg structure. After all messages have been added to the
   buffer, the original start address and the resulting length has to
   be written to the structure. I'm currently doing this in
   rt_udp_recvmsg (just before "return") but I believe there is a
   better place...

* I don't understand how to implement socket options. Is it okay to
   just introduce a new ioctl, or is it better to use setsockopt? I'm
   just unsure where to implement this. Currently I wrote some code to
   ip_sock.c in stack/ipv4 but that's wrong. It currently doesn't work
   because of the level... The Linux Kernel has got the file sock.c
   which implements a handler for SOL_SOCKET. Is there a simple method
   to use setsockopt, or is it better to just introduce a new ioctl?

* Is it a good idea to support a similar interface as normal
   SO_TIMESTAMPNS which requires to transform nanosecs_abs_t to a
   timespec structure?  To support this, I would have to evaluate a
   division and a modulo operation of a 64bits variable and a 32bit
   constant. I'm not sure whether this is a good idea or not. Currently
   I'm thinking about inventing a new cmsg identifier and flag to just
   copy the nanosecs variable and also support SO_TIMESTAMPNS (which
   will introduce some extra latency when active).

I'm looking forward to your comments. Please let me know if you have
better ideas to implement this, I would love to improve the current
implementation ;)

Best regards, Manuel

Re: [RTnet-developers] SO_TIMESTAMPNS for RTnet

[Jan K. <jan...@we...>]

On 2013-05-19 10:24, Manuel Huber wrote:
> Hello!
> 
> I'm currently working on a patch for RTnet
> (https://bitbucket.org/robinreal/rtnetts/overview exp branch) that
> enables the user to retrieve time stamps from the driver (via
> recvmsg). Currently development is not finished, there are still
> bugs and I need to rewrite commit messages. Overview:
> 
> * I hooked into the rt_udp_recvmsg function to optionally add time
>    stamps to the msghdr struct. The rt_socket_recv_timestamp function
>    is used to actually retrieve put the time stamp into the cmsg
>    buffer. This could maybe also be used for other protocols (?).
> 
> * In stack/scm.c the original put_cmsg function has been ported to
>    RTDM. Currently I haven't yet implemented the put_cmsg_compat
>    function.
> 
> * In rtnet_socket.h I added a member sk_flags, which could be used for
>    various other functions. This is used to activate and deactivate
>    passing time stamps to the user (through msghdr structure).
> 
> * CONFIG_RTNET_SO_TIMESTAMPNS can be used to control whether RTnet
>    stack supports passing timestamps to user-space or not.

Still need to study this. Will have a look these days while traveling.

> 
> 
> During implementation I ran into some problems:
> 
> * I couldn't really find out, where the "normal" Linux Kernel fixes
>    the cmsg structure. After all messages have been added to the
>    buffer, the original start address and the resulting length has to
>    be written to the structure. I'm currently doing this in
>    rt_udp_recvmsg (just before "return") but I believe there is a
>    better place...

You could run the kernel against a debugger (kgdb or the built-in
gdbserver of QEMU/KVM) and set a watchpoint...

> 
> * I don't understand how to implement socket options. Is it okay to
>    just introduce a new ioctl, or is it better to use setsockopt? I'm
>    just unsure where to implement this. Currently I wrote some code to
>    ip_sock.c in stack/ipv4 but that's wrong. It currently doesn't work
>    because of the level... The Linux Kernel has got the file sock.c
>    which implements a handler for SOL_SOCKET. Is there a simple method
>    to use setsockopt, or is it better to just introduce a new ioctl?

You receive setsockopt request via an official IOCTL from the RTDM
layer. Watch out for _RTIOC_SETSOCKOPT.

> 
> * Is it a good idea to support a similar interface as normal
>    SO_TIMESTAMPNS which requires to transform nanosecs_abs_t to a
>    timespec structure?  To support this, I would have to evaluate a
>    division and a modulo operation of a 64bits variable and a 32bit
>    constant. I'm not sure whether this is a good idea or not. Currently
>    I'm thinking about inventing a new cmsg identifier and flag to just
>    copy the nanosecs variable and also support SO_TIMESTAMPNS (which
>    will introduce some extra latency when active).

On x86, the conversion will be barely visible. But on low-end archs, it
may make a little difference. However, supporting a standard interface
makes some sense to ease portability, so you should have SO_TIMESTAMPNS.
An optimized interface could be added on demand.

Jan

Re: [RTnet-developers] SO_TIMESTAMPNS for RTnet

[Jan K. <jan...@we...>]

On 2013-05-27 07:45, Jan Kiszka wrote:
> On 2013-05-19 10:24, Manuel Huber wrote:
>> Hello!
>>
>> I'm currently working on a patch for RTnet
>> (https://bitbucket.org/robinreal/rtnetts/overview exp branch) that
>> enables the user to retrieve time stamps from the driver (via
>> recvmsg). Currently development is not finished, there are still
>> bugs and I need to rewrite commit messages. Overview:
>>
>> * I hooked into the rt_udp_recvmsg function to optionally add time
>>    stamps to the msghdr struct. The rt_socket_recv_timestamp function
>>    is used to actually retrieve put the time stamp into the cmsg
>>    buffer. This could maybe also be used for other protocols (?).
>>
>> * In stack/scm.c the original put_cmsg function has been ported to
>>    RTDM. Currently I haven't yet implemented the put_cmsg_compat
>>    function.
>>
>> * In rtnet_socket.h I added a member sk_flags, which could be used for
>>    various other functions. This is used to activate and deactivate
>>    passing time stamps to the user (through msghdr structure).
>>
>> * CONFIG_RTNET_SO_TIMESTAMPNS can be used to control whether RTnet
>>    stack supports passing timestamps to user-space or not.
> 
> Still need to study this. Will have a look these days while traveling.

First remark: You are mixing changes of different kind in your commits.
Specifically changes to generated autotools are better kept separate
from code changes (including changes to autotools input files). Same for
coding style changes. That will ease the review later on. Fortunately,
git allows you reorganize things as often as you like ;).

Oh, and something is fairly broken in your tree over there. Looks like
one commit deletes all the generated autotools files...

BTW, I don't think this feature has to be optional at compile time. It
only adds a single if to the hotpath, not really expensive. And you
should really measure the difference between TIMESTAMPNS64 and
TIMESTAMPNS. What is your target arch?

Jan