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.042429.194566531.davem@davemloft.net>
Date:	Mon, 16 Nov 2009 04:24:29 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	B05799@...escale.com
Cc:	vladz@...adcom.com, netdev@...r.kernel.org, eilong@...adcom.com
Subject: Re: [net-next] bnx2x: Handle Rx and Tx together in NAPI

From: "Kumar Gopalpet-B05799" <B05799@...escale.com>
Date: Mon, 16 Nov 2009 17:26:33 +0530

> In the current implemnetation, the ->poll() function does the cleanup of
> the tx and rx rings of the same device.
> In case of forwarding scenarios (for eg, eth0 --> eth1) we should clean
> the tx ring of eth1 so that the buffers can be reclaimed and they be
> reused for eth0 RX and same is the case for opposite flow. With the
> current implementation there will be a problem for the bidirectional
> flow as a ->poll() function will try to cleanup the rx and tx ring of
> the same device.
> 
> Hence I feel, if we separate out the tx and rx clean ring processes, it
> would be more advantageous as the reclaim process can be more effective.

Eric Dumazet is working on patches to make sure the TX frees
get scheduled on the same CPU as they were transmitted on.

Therefore, you shouldn't try to approximate this in your driver.
--
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