netdev - Re: [RFC][PATCH 1/2] net: support for TX timestamps

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]

Date:	Wed, 30 Jul 2008 14:43:33 +0200
From:	Patrick Ohly <patrick.ohly@...el.com>
To:	Octavian Purdila <opurdila@...acom.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC][PATCH 1/2] net: support for TX timestamps

On Tue, 2008-07-29 at 03:35 +0300, Octavian Purdila wrote:
> The actual timestamp will reach userspace as a RX timestamp on the
> cloned packet. If timestamping is requested and no timestamping is
> done in the device driver (potentially this may use hardware
> timestamping), it will be done in software after the device's
> start_hard_xmit routine.

This needs to be augmented to not fall back to software time stamping,
as discussed in "[RFC][PATCH 1/1] net: support for hardware
timestamping".

Apart from that the API looks okay. It should be fairly simple to adapt
PTPd.

> @@ -1568,6 +1576,8 @@ static int dev_gso_segment(struct sk_buff *skb)
>  
>  int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
>  {
> +	int rc;
> +
>  	if (likely(!skb->next)) {
>  		if (!list_empty(&ptype_all))
>  			dev_queue_xmit_nit(skb, dev);
> @@ -1579,13 +1589,15 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
>  				goto gso;
>  		}
>  
> -		return dev->hard_start_xmit(skb, dev);
> +		rc = dev->hard_start_xmit(skb, dev);
> +		if (likely(!rc))
> +			net_tx_timestamp(skb);
> +		return rc;
>  	}

How do you recognize whether the driver did hardware time stamping? Hmm,
okay, I think I can answer that myself: if the driver supports hardware
time stamping, it must clear tstamp in its hard_start_xmit(). Later on
when it has transmitted the packet, it extracts the corresponding
hardware time stamp and calls skb_tx_timestamp(). Right? If so, this
should go into a comment somewhere.

The implicit assumption here is that drivers do not touch tstamp,
because otherwise software time stamping might accidentally be disabled
by a driver. That seems to be the case, at least for in-kernel drivers.

Is skb->sk always guaranteed to be set in hard_start_xmit?
skb_tx_timestamp() depends on it. In 2.6.23 the field always seemed to
be valid, but in 2.6.26 I think I have seen NULL pointers there for PTP
UDP broadcasts.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

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