[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Sep 2010 10:31:45 -0400
From: "Loke, Chetan" <Chetan.Loke@...scout.com>
To: "Eric Dumazet" <eric.dumazet@...il.com>,
"Richard Cochran" <richardcochran@...il.com>
Cc: "Ingo Kofler" <ikofler@....uni-klu.ac.at>, <netdev@...r.kernel.org>
Subject: RE: Problems obtaining software TX timestamps
> From: netdev-owner@...r.kernel.org [mailto:netdev-
> owner@...r.kernel.org] On Behalf Of Eric Dumazet
> Sent: September 09, 2010 10:03 AM
> To: Richard Cochran
> Cc: Ingo Kofler; netdev@...r.kernel.org
> Subject: Re: Problems obtaining software TX timestamps
>
> Le jeudi 09 septembre 2010 à 15:57 +0200, Richard Cochran a écrit :
> > On Thu, Sep 09, 2010 at 10:26:06AM +0200, Ingo Kofler wrote:
> > > Thank you very much for this clarification. Are there any drawbacks
> > > with this approach, e.g. performance issues? Honestly, I am just
> > > wondering why driver developers do not add this single line if it's
> > > that easy....
> >
> > Adding the line only tests one flag, so it is not a huge performance
> > hit. This fix is very recent, that is why it has not been used in MAC
> > drivers yet.
>
> Should drivers call it at start_xmit() time, or at tx completion time ?
>
> 1) start_xmit() time : Earlier than real hardware xmit (with up to 1000
> packets queued in TX ring, delay might be very large)
>
> 2) tx completion time : After real hardware xmit
> (on tg3, ethtool -c gives : tx-usecs: 72 , tx-frames: 53, so we can
> have a delay of 72 us before NIC acknowledges the frame xmit)
>
I'm not familiar w/ the code but I would think right before the Tx-descriptors are posted. That is, before a pci-write, where the Tx-queue put
ptrs are updated. Because if the NIC is overloaded then there will be some delay before the pkts are Xmit'd. But if there is a N/W TAP then we would atleast roughly know where we could start troubleshooting.
Chetan Loke
Powered by blists - more mailing lists