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
| ||
|
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
Powered by blists - more mailing lists