Re: Flows! Offload them.

[Florian Fainelli <f.fainelli@gmail.com>]

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@gmail.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