[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150305.014257.974664546228241067.davem@davemloft.net>
Date: Thu, 05 Mar 2015 01:42:57 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: therbert@...gle.com
Cc: john.fastabend@...il.com, davidch@...adcom.com,
simon.horman@...ronome.com, dev@...nvswitch.org,
netdev@...r.kernel.org, pablo@...filter.org
Subject: Re: [ovs-dev] OVS Offload Decision Proposal
From: Tom Herbert <therbert@...gle.com>
Date: Wed, 4 Mar 2015 21:20:41 -0800
> On Wed, Mar 4, 2015 at 9:00 PM, David Miller <davem@...emloft.net> wrote:
>> From: John Fastabend <john.fastabend@...il.com>
>> Date: Wed, 04 Mar 2015 17:54:54 -0800
>>
>>> I think a set operation _is_ necessary for OVS and other
>>> applications that run in user space.
>>
>> It's necessary for the kernel to internally manage the chip
>> flow resources.
>>
>> Full stop.
>>
>> It's not being exported to userspace. That is exactly the kind
>> of open ended, outside the model, crap we're trying to avoid
>> by putting everything into the kernel where we have consistent
>> mechanisms, well understood behaviors, and rules.
>
> David,
>
> Just to make sure everyone is on the same page... this discussion has
> been about where the policy of offload is implemented, not just who is
> actually sending config bits to the device. The question is who gets
> to decide how to best divvy up the finite resources of the device and
> network amongst various requestors. Is this what you're referring to?
I'm talking about only the kernel being able to make ->set() calls
through the flow manager API to the device.
Resource control is the kernel's job.
You cannot delegate this crap between ipv4 routing in the kernel,
L2 bridging in the kernel, and some user space crap. It's simply
not going to happen.
All of the delegation of the hardware resource must occur in the
kernel. Because only the kernel has a full view of all of the
resources and how each and every subsystem needs to use it.
--
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
Powered by blists - more mailing lists