netdev - Re: [rfc] new sk_buff member: hwstamp

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

Date:	Mon, 14 Jul 2008 21:49:24 +0300
From:	Octavian Purdila <opurdila@...acom.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	netdev@...r.kernel.org
Subject: Re: [rfc] new sk_buff member: hwstamp

On Monday 14 July 2008, Andi Kleen wrote:

>
> You only need this between the driver and the socket recvmsg(), don't you?
>

Correct.

> One possible alternative (I admit I haven't thought all the implications
> through) would be to use a second magic internal skb for this which has the
> same UDP header, but as only payload the time stamp. Disadvantage would
> be the requirement to do header parsing in the driver, but often
> hardware does that already.
>

Hmm, this sounds interesting. 

Maybe only keep the timestamp without the UDP header and queue the skb 
as "ancillary" data?

And we can probably do this in a generic way for all sort of socket types 
(PF_PACKET comes to mind) - just add a special ancillary data queue in the 
socket. Sure this would mean stuffing the sockets structures - not very 
different from adding new stuff in skb :), but I feel it is a bit more 
generic: an easy to extend channel of communication between drivers/hw and 
userspace without future structures overhead. 

And I think this will help with solving the hw TX stamp problem I am looking 
into, as well (how to send the hw generated TX stamp to application). 

Thanks,
tavi
--
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