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

Message-ID: <CALCETrV_Zk6GWROQK8hEDwFzUDCtW_HX_xC5QhAFVXPzwgurXQ@mail.gmail.com>
Date:	Sun, 9 Mar 2014 10:33:29 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Ben Hutchings <ben@...adent.org.uk>
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, 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?

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.

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