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:	Thu, 05 Mar 2015 06:52:14 -0800
From:	John Fastabend <john.fastabend@...il.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
CC:	David Miller <davem@...emloft.net>, therbert@...gle.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

On 03/05/2015 05:16 AM, Jamal Hadi Salim wrote:
> On 03/05/15 07:37, Jamal Hadi Salim wrote:
>> On 03/05/15 02:39, John Fastabend wrote:
>
>> Would kernel boot/module options passed to the driver not suffice?
>> That implies a central authority that decides what these table size
>> slicing looks like.
>>

The problem with boot/module options is they are really difficult to
manage from a controller agent. And yes in most cases I am working on
there is central authority that "knows" how to map the network policy
onto a set of table size slices. At least in my space I don't believe
people are logging into systems and using the CLI except for debugging
and experimenting.

>>> Once the reservation of resources occurs we wouldn't let user space
>>> arbitrarily write to any table but only tables that have been
>>> explicitly reserved for user space to write to.
>
> Seems i misread what you are saying.
> I thought you wanted to just create the tables from user space
> directly; however, rereading the above:
> you are actually  asking *to write* to these tables directly from user
> space ;->
>
>

Actually I was proposing both. But I can see a workaround for the set
rule or *to write* by mapping a new xflow classifier onto my hardware.
Not ideal for my work but I guess it might be possible.

The 'create' table from user space though I don't see any good work
around for. You need this in order to provide some guidance to the
driver otherwise we have to try and "guess" what the table size slicing
should look like and this can create rather large variations in how
many rules fit in the table think 100 - 100k difference. Also at least
on the hardware I have this is not dynamic I can't start adding rules
to a table and then do a resizing later without disrupting the traffic.
It would be interesting for folks working on other switch devices to
chime in.

Also just to the point out even in the 'set' case we wouldn't let
arbitrary 'set rule' writes hit the hardware we would verify the rule
set is for a table that is pre-defined for it and that the rule itself
is well-formed. In that sense the xflow classifier path is not
particularly different.

cheers,
> jamal

-- 
John Fastabend         Intel Corporation
--
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