netdev - Re: TX timestamping for ICMP (sfc and core)?

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: <1394392675.15968.21.camel@deadeye.wl.decadent.org.uk>
Date:	Sun, 09 Mar 2014 19:17:55 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Network Development <netdev@...r.kernel.org>,
	Solarflare linux maintainers <linux-net-drivers@...arflare.com>
Subject: Re: TX timestamping for ICMP (sfc and core)?

On Sun, 2014-03-09 at 10:33 -0700, Andy Lutomirski wrote:
> On Sun, Mar 9, 2014 at 10:07 AM, Ben Hutchings <ben@...adent.org.uk> wrote:
> > On Tue, 2014-03-04 at 12:43 -0800, Andy Lutomirski wrote:
> >> I'm trying to get tx timestamping working on ping sockets.  My program
> >> works fine (with hardware TX timestamps) if I send my "pings" on the
> >> PTP UDP ports.  I want to send real ICMP pings, though.
> >>
> >> It looks like there are two problems:
> >>
> >>  - Something in the core code seems to eat SKBTX_HW_STAMP on ping
> >> sockets.  At least, this code in efx_hard_start_xmit triggers for
> >> IPPROTO_UDP on PTP ports but not for IPPROTO_ICMP:
> >>
> >>         if (unlikely(efx_xmit_with_hwtstamp(skb)))
> >>                 printk(KERN_DEBUG "sfc: trying to do a TX timestamp\n");
> >>
> >>  - The sfc driver refuses to timestamp non-PTP packets.  There's a
> >> check in efx_hard_start_xmit and another in ptp.c.  I suspect that the
> >> hardware can support timestamping any outgoing packet, but I'm not
> >> really sure.  (I'm using an SFN7322F.)
> >
> > I think that the SFC9100 family can do TX timestamping for arbitrary
> > packets, but they still have to be sent via the MC and that will greatly
> > limit the packet rate.
> >
> > (It may or may not be possible on the SFN[56]322F, as the addition of
> > timestamping in a peripheral to the SFC9020 is quite a delicate
> > arrangement.  The MCDI transport there also limits TX timestamped
> > packets to 252 bytes.)
> >
> > If you want to send more than a very low rate of packets with TX
> > timestamping, the driver should probably tell the kernel to allocate an
> > extra TX queue for them and should implement ndo_select_queue.
> 
> All of these packets should be flagged with SKBTX_HW_TSTAMP, so the
> driver will know that they need special treatment.  Is the issue that,
> if they end up on a queue with other packets, that they will block the
> other packets?

I think they might, because bql will count both packets in a hardware TX
queue and packets that were diverted to the software PTP queue.  I'm not
sure how much of a problem that could actually become.

> In any case, doing this on older hardware is probably useless, at
> least for me.  I want to implement fully hardware-timestamped ping (to
> be open-sourced once it works), and TX timestamps on echo requests
> aren't terribly useful without RX timestamps on echo replies / TTL
> exceeded messages, and the latter is impossible on older hardware, I
> think.

Right.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.

Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)