netdev - Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits

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]

Message-ID: <20110809075454.5331dcac@nehalam.ftrdhcpuser.net>
Date:	Tue, 9 Aug 2011 07:54:54 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>, therbert@...gle.com,
	netdev@...r.kernel.org
Subject: Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits

On Tue, 09 Aug 2011 10:06:13 +0200
Eric Dumazet <eric.dumazet@...il.com> wrote:

> Le mardi 09 août 2011 à 00:41 -0700, David Miller a écrit :
> > From: Stephen Hemminger <shemminger@...tta.com>
> > Date: Mon, 8 Aug 2011 11:19:17 -0700
> > 
> > > On Mon, 8 Aug 2011 11:01:57 -0700
> > > Tom Herbert <therbert@...gle.com> wrote:
> > > 
> > >> > Since transmit completion means calling dev_kfree_skb() why not account
> > >> > there? You could add some info to netdev if necessary to get compile
> > >> > the statistics.
> > >> >
> > >> The algorithm depends on knowing the total number of packets competed
> > >> in a single execution of transmit completion (epic based).  We only
> > >> want to recalculate the limits once per completion, which happens when
> > >> the completion function is called.
> > > 
> > > So just add some stats to netdev and count the number of dev_kfree_skb
> > > calls and do your work at napi complete.
> > 
> > No, I think what Tom's doing here is reasonable.
> > 
> > First off, drivers have never been required to do specific things if
> > they return success for ->ndo_start_xmit().  They can kfree_skb(skb)
> > and return NET_TX_SUCCESS, and that's fine.
> > 
> > This mean we can't use ->ndo_start_xmit() return values to drive the
> > BQL engine.
> > 
> > So we simply have a way for the driver to say when it really does
> > queue up a packet, and that might be useful for other things.
> > 
> > Second, you absolutely do not want to run the BQL engine on every
> > single dev_kfree_skb() call.  You want to batch it, and that's what
> > Tom's new interface does, and that is therefore quite reasonable
> > too.
> > 
> > In fact, I think the best part about this revision of the BQL patches
> > is the device driver interface. :-)
> > 
> 
> I agree, it permits a smooth transition to selected drivers, even some
> non NAPI ones ;)
> 
> In some stress situations, NAPI never completes, so it would also mean
> adding a dql call in this case...

Ok. then we need to fix all NAPI drivers at once, and get more
drivers converted over to NAPI. It is really annoying how there
is just too much variation among network drivers.

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