On Mon, Mar 2, 2015 at 5:49 AM, Andy Gospodarek
[off-list ref] wrote:

On Thu, Feb 26, 2015 at 05:52:16PM -0800, Tom Herbert wrote:

quoted

On Thu, Feb 26, 2015 at 5:22 PM, Neil Horman [off-list ref] wrote:

[...]

quoted

quoted

Yes, exactly that, for the general traditional networking use case, that is
exactly what we want, to opportunistically move traffic faster with less load on
the cpu.  We don't nominally care what traffic is offloaded, as long as the
hardware does a better job than just software alone.  If we get an occasional
miss and have to do stuff in software, so be it.

+1 on an in kernel "Network Resource Manager". This also came up in
Sunil's plan to configure RPS affinities from a driver so I'm taking
liberty by generalizing the concept :-).

I agree completely that there is a need for what you both describe.  Not
only to handle what items to offload for users looking for that level
of granularity, but also to allow driver implementers to decide if their
hardware/driver implementation may allow for async write of data to
hardware tables, and any other implementation specific detail they may
want to provide.

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