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  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]
Date:	Sun, 09 Mar 2014 19:17:55 +0000
From:	Ben Hutchings <>
To:	Andy Lutomirski <>
Cc:	Network Development <>,
	Solarflare linux maintainers <>
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 <> 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.



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)

Powered by blists - more mailing lists