netdev - Re: TX time stamping

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

Message-Id: <1238482421.11761.19.camel@pohly-MOBL>
Date:	Tue, 31 Mar 2009 08:53:41 +0200
From:	Patrick Ohly <patrick.ohly@...el.com>
To:	Oliver Hartkopp <oliver@...tkopp.net>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
Subject: Re: TX time stamping

On Mon, 2009-03-30 at 21:09 +0300, Oliver Hartkopp wrote:
> i wonder if using the IP stack for PTP with the possibility to send TX-stamped
>  PDUs on various interfaces is the best solution.

PTPd already only sends on one interface. How to deal with packets that
go out via multiple interfaces becomes relevant when generalizing the
hardware time stamping concept.

> I'm not aware of all the routing, packet scheduling, etc. stuff that much -
> but does it probably make sense to use AF_PACKET for PTP, where you can
> specify the interface and build a PTP IP PDU directly? I assume this does not
> make that big difference to the ptpd in userspace.

I'm not familiar with AF_PACKET. It let's user space assemble the
complete packet (including Ethernet header) and send directly via a
specific interface, right?

The drawback is that the user space daemon would have to reimplement the
joining/leaving of a multicast group. When using the IP stack, it can
let the kernel do that.

It also still uses write() or sendmsg(), doesn't it? In that case
there's no advantage over the current approach because the only link
back to the sender is still only the socket.

But perhaps I am simply unaware of some aspects of the socket API for
AF_PACKET. Is there something which would allow implementing Herbert's
approach with communication via sh_info when the sender is in user
space?

Herbert, what do you think about the "identify socket via unique ID"
idea? Is that possible/doable/acceptable/stupid/all of these?

-- 
Best Regards

Patrick Ohly
Senior Software Engineer

Intel GmbH
Software & Solutions Group                
Hermuelheimer Strasse 8a                  Phone: +49-2232-2090-30
50321 Bruehl                              Fax: +49-2232-2090-29
Germany

--
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