netdev - Re: [PATCH net-next] bnx2x: Do Tx handling in a separate tasklet.

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] [day] [month] [year] [list]

Message-Id: <20091028.025742.32857568.davem@davemloft.net>
Date:	Wed, 28 Oct 2009 02:57:42 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	vladz@...adcom.com
Cc:	IMCEAMAILTO-davem+40davemloft+2Enet@...adcom.com,
	eilong@...adcom.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] bnx2x: Do Tx handling in a separate tasklet.

From: "Vladislav Zolotarov" <vladz@...adcom.com>
Date: Wed, 28 Oct 2009 02:54:37 -0700

> I'd like to start from your last remark: you r absolutely right, and this is the problem we have in the current net-next driver. More than that, this patch is fixing this problem: it moved liberation of Tx SKBs from hardIRQ context (ISR) to the softIRQ context (tasklet) thereby resolving the problem u've mentioned. So, total agreement with u on this one. I must have named the patch differently to emphasize it.
> 
> I'd like to summarize the patch I've sent:
> - Take Tx SKB liberation out of hardIRQ.
> - Instead schedule a DPC that handles Tx work.
> - Optimize the access to status block indices: read only the index we are about to use in the current context.
> 
> So, could u, pls., apply the patch in order to fix the problem we currently have in bnx2x?

There is no reason not to use NAPI to achieve this objective and that's
the main objection I have to your patch.

Using NAPI will not only allow you to move the SKB freeing to softirq
context but it will also provide fairness between multiple NAPI
contexts active at the same time on the same cpu.

Furthermore, if you combine RX and TX NAPI work for a specific queue
into the same NAPI context, TX liberation can run first and provide
fresh CPU local SKBs for RX packet input processing created replies
to allocate.

You haven't addressed any of that, and I am not going to apply your
patch becuase I don't want your driver to set a precedence here.
--
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