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

Powered by Openwall GNU/*/Linux Powered by OpenVZ