netdev - Re: [ovs-dev] OVS Offload Decision Proposal

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 4 Mar 2015 21:20:41 -0800
From:	Tom Herbert <therbert@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	john fastabend <john.fastabend@...il.com>,
	David Christensen <davidch@...adcom.com>,
	Simon Horman <simon.horman@...ronome.com>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Pablo Neira Ayuso <pablo@...filter.org>
Subject: Re: [ovs-dev] OVS Offload Decision Proposal

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?

Thanks,
Tom
--
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