[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <491B4BE3.3010104@linux.intel.com>
Date: Wed, 12 Nov 2008 22:34:27 +0100
From: Andi Kleen <ak@...ux.intel.com>
To: Eric Dumazet <dada1@...mosbay.com>
CC: Oliver Hartkopp <oliver@...tkopp.net>,
Patrick Ohly <patrick.ohly@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Octavian Purdila <opurdila@...acom.com>,
Stephen Hemminger <shemminger@...tta.com>,
Ingo Oeser <netdev@...eo.de>,
"Ronciak, John" <john.ronciak@...el.com>
Subject: Re: [RFC PATCH 00/13] hardware time stamping + igb example implementation
Eric Dumazet wrote:
> This scheme only is needed for special devices,
It's going to be supported by a large range of mass market NICs,
not special devices.
used by PTP.
>
> Only *selected* frames really need to gather hwtstamp.
Yes but the NIC cannot decide that.
> TCP trafic wont use hwtstamp.
Actually it wouldn't surprise me if one of the numerous
TCP congestion avoidance algorithms that get added all the time
starts making use of such an enhanced time stamp.
>Most UDP trafic wont use hwstamp.
That depends. For example if you're running a packet sniffer
most packets will carry it. Probably also others. e.g. dhcp
is using timestamps and it would make sense to switch it to
hw timestamps when available.
Now if you're running a DHCP server ...
> I threw a "crazy idea", that can be changed if necessary, say with a cookie
> that identifies the slot in NIC driver structure. O(1) lookup if really
> needed.
I think "crazy" describes it well because it would be a lot of dubious
and likely not performing well effort just to save 8 bytes.
BTW it wouldn't surprise me if skb heads had some free space in common
situations anyways becaus it's unlikely it fits exactly into 4K pages
in slab/slub.
-Andi
--
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