[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1227098369.16263.39.camel@ecld0pohly>
Date: Wed, 19 Nov 2008 13:39:29 +0100
From: Patrick Ohly <patrick.ohly@...el.com>
To: Oliver Hartkopp <oliver@...tkopp.net>
Cc: Andi Kleen <ak@...ux.intel.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>,
Eric Dumazet <dada1@...mosbay.com>
Subject: Re: [RFC PATCH 00/13] hardware time stamping + igb example
implementation
On Wed, 2008-11-12 at 18:44 +0000, Oliver Hartkopp wrote:
> I really wondered if you posted the series to get an impression why
> adding a new field is a good idea ;-)
Oh dear, my secret plan has been revealed ;-) No, I was really hoping
that the patch would be acceptable. After rewriting the patch series
with one additional field the code is simpler (or so I hope). I just
posted it to linux-kernel and linux-net.
> I would also vote for having a new field in the
> skb instead of this current 'bit-compression' approach which smells
> quite expensive at runtime and in code size. Not talking about the
> mentioned potential locking issues ...
The locking issues still remain: the hardware reconfiguration in the
ioctl needs to be coordinated with the ongoing time stamping. Then
there's the raw2sys callback which is made by the socket layer into the
device. That one is problematic also because finding that device isn't
as easy as I thought (see my other mails), so perhaps we should get rid
of the delayed transformation and add two fields.
--
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
Powered by blists - more mailing lists