netdev - Re: [PATCH RFC]: napi

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070807.160651.98554604.davem@davemloft.net>
Date:	Tue, 07 Aug 2007 16:06:51 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	rdreier@...co.com
Cc:	netdev@...r.kernel.org, shemminger@...ux-foundation.org,
	jgarzik@...ox.com, hadi@...erus.ca, rusty@...tcorp.com.au
Subject: Re: [PATCH RFC]: napi_struct V5

From: Roland Dreier <rdreier@...co.com>
Date: Tue, 07 Aug 2007 15:37:30 -0700

>  >  		n = ib_poll_cq(priv->cq, t, priv->ibwc);
>  >  
>  > -		for (i = 0; i < n; ++i) {
>  > +		for (i = 0; i < n; i++) {
> 
> it might be nicer to avoid noise like this in the patch.

That one was just too much of an eye sore to ignore and it
effect my ability to audit the change I was making.

I mean, this is one of the first precise examples of kinds of
programming that lead to subtle bugs mentioned in The Practice of
Programming.

So this is staying in the patch, sorry.

> this goto back to the polling loop is a change in behavior.  When we
> were tuning NAPI, we found that returning in the missed event case and
> letting the NAPI core call the poll routine later actually performed
> better, because it allowed more work to pile up.

You weren't using your quantum, which is what you're supposed to do.

Sometimes using your quantum correctly won't perform optimally, but in
the interest of fairness and what NAPI wants, that is what you're
supposed to do, process work until you hit budget or there is no
more work.

Look, I'm not going to back down to every single tweak in every
driver.  All the drivers should handle this case consistently, and if
I have to edit every single driver to make this patch that is exactly
what I am going to do and enforce.

If you patch the ipoib driver behavior back afterwards, I will NAK
that patch every single time unless you make EVERY SINGLE OTHER DRIVER
do the same and thus retain the consistency.
-
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