netdev - Re: [net-next] bnx2x: Handle Rx and Tx together in 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20091116.032400.204096446.davem@davemloft.net>
Date:	Mon, 16 Nov 2009 03:24:00 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	vladz@...adcom.com
Cc:	netdev@...r.kernel.org, eilong@...adcom.com
Subject: Re: [net-next] bnx2x: Handle Rx and Tx together in NAPI

From: "Vladislav Zolotarov" <vladz@...adcom.com>
Date: Mon, 16 Nov 2009 03:11:27 -0800

> To say the truth, limiting the amount of Tx work done in one NAPI
> round is about to harm single NAPI performance, however I thought it
> would be a nice thing to do in global (all network devices/queues in
> the system) perspective. In Tx only case: when all NAPIs do only Tx
> DPC work (UDP Tx only case) I need to ensure fairness somehow, so I
> chose NAPI's budget. Could u advice on this?

The extra loop you'll trigger in the code above ->poll() that loops
over NAPI context is more expensive than the TX freeing work.

The size of your TX ring will be enough all by itself to ensure
enough fairness.

If you try to use the NAPI quota, you're just adding overhead.

> There is another decision to make: what to do when Rx hasn't
> consumed the whole budget and there is still Tx work to do. I think
> that in this case we need to return "budget", so that we pushed to
> the end on the local NAPI's list, "consuming" some global Rx budget
> of the local NAPI. Another option is to return the number of Rx
> packets handled and make this NAPI be called at once. My decision is
> based on the fact that there were scenarios when net_tx_action and
> net_rx_action were running on different CPUs in UDP Tx test and were
> feeding each other. In this case if I implemented the later option I
> would prevent other local NAPIs to run.

I think you should always process all of the pending TX work first,
then do RX work and base your budget and rescheduling decisions
purely on RX work.

If you want to see it codified look at the tg3 driver or any other
driver that has been NAPI for a long ti me.
--
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