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:	Fri, 09 Jan 2015 09:26:07 -0800
From:	John Fastabend <john.fastabend@...il.com>
To:	Or Gerlitz <gerlitz.or@...il.com>
CC:	Thomas Graf <tgraf@...g.ch>, Scott Feldman <sfeldma@...il.com>,
	Jiří Pírko <jiri@...nulli.us>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	simon.horman@...ronome.com,
	Linux Netdev List <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Andy Gospodarek <andy@...yhouse.net>
Subject: Re: [net-next PATCH v1 00/11] A flow API

On 01/08/2015 07:14 AM, Or Gerlitz wrote:
> On Wed, Dec 31, 2014 at 9:45 PM, John Fastabend
> <john.fastabend@...il.com> wrote:
>> For some examples and maybe a bit more illustrative description I
>> posted a quickly typed up set of notes on github io pages. Here we
>> can show the description along with images produced by the flow tool
>> showing the pipeline. Once we settle a bit more on the API we should
>> probably do a clean up of this and other threads happening and commit
>> something to the Documentation directory.
>>
>>   http://jrfastab.github.io/jekyll/update/2014/12/21/flow-api.html
>
> John, Going over your excellent tutorial, the distinction between
> action and operation isn’t clear... specifically, the paragraph
> “Although this gives us a list of actions we can perform on a packet
> and a set of argument to give the action so we can use them it does
> not supply the operations performed on the packet” is a bit vague.
>
> Or.
>

Agreed that is a bit confusing. What I was trying to show is if two
hardware devices give you the same action but with different names
showing they are equivalent is not possible with the current API.
So either (a) you need to enforce every device names their actions
correctly or (b) provide a mechanism to describe the actions so we
can evaluate their equivalence.

Its actually worse then this what I want to eventually show is if
device A has support for a set of actions and device B has support
for another set. I want to be able to say things about the devices
like device A can support any action B can do but it may require
applying a 2 actions from A's collection of actions. (clear as mud?)
I'll try to clear it up in the documentation.

Thanks for looking it over.
.John

-- 
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ