netdev - Re: Flows! Offload them.

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]

Date:	Mon, 02 Mar 2015 14:49:58 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Andy Gospodarek <gospo@...ulusnetworks.com>,
	Scott Feldman <sfeldma@...il.com>
CC:	Shrijeet Mukherjee <shrijeet@...il.com>,
	Tom Herbert <therbert@...gle.com>,
	Neil Horman <nhorman@...driver.com>,
	Simon Horman <simon.horman@...ronome.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Thomas Graf <tgraf@...g.ch>, Jiri Pirko <jiri@...nulli.us>,
	Linux Netdev List <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Andy Gospodarek <andy@...yhouse.net>,
	Daniel Borkmann <dborkman@...hat.com>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Jesse Gross <jesse@...ira.com>,
	"jpettit@...ira.com" <jpettit@...ira.com>,
	Joe Stringer <joestringer@...ira.com>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	John Linville <linville@...driver.com>,
	Benjamin LaHaise <bcrl@...ck.org>
Subject: Re: Flows! Offload them.

On 02/03/15 14:43, Andy Gospodarek wrote:
> On Mon, Mar 02, 2015 at 02:13:35PM -0800, Scott Feldman wrote:
>> On Mon, Mar 2, 2015 at 10:31 AM, Shrijeet Mukherjee <shrijeet@...il.com> wrote:
>>>>
>>>> Can you elaborate on "allow for async write of data to hardware
>>>> tables"?  Is this the trampoline model where user's request goes to
>>>> the kernel, and then back to user-space, and finally to the hardware
>>>> via an user-space SDK?  I think we should exclude that model from
>>>> discussions about resource management.  With the recent L2/L3 offload
>>>> work, I'm advocating a synchronous call path from user to kernel to
>>>> hardware so we can return a actionable result code, and put the burden
>>>> of resource management in user-space, not in the kernel.
>>>>
>>> Scott you mean synchronous to the switchdev driver right ?
>>
>> Correct.
> 
> So while I agree with you that it would be ideal to be synchronous all
> the way to the hardware (and that is what I continue to tell vendors
> they should do) you would like to see each driver individually manage
> whether or not they chose to make these calls async and handle the
> fallout in their own?

I am not sure I follow you here, the way I would see it is something
like this:

SWITCHDEV	DRIVER
ndo_foo ->
		foo_op ->
			bus_op() ->
			# wait for interrupt
			complete()
ndo_foo 	<- return

at which point, the only things that matters is that the switch driver
ensures calls serialization at its own level (concurrent HW registers
access), eventually working under the assumption that ndo_foo() is also
called with appropriate locking (rtnl) to prevent concurrent operations
from occurring.

If the model is more like the switch driver is responsible for locally
queuing multiple commands, then I agree, we might not want that at all.

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