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.
Once the reservation of resources occurs we wouldn&#
On 03/05/15 02:39, John Fastabend wrote:
The intent was to reserve space in the tables for l2, l3, user space,
and whatever else is needed. This reservation needs to come from the
administrator because even the kernel doesn't know how much of my
table space I want to reserve for l2 vs l3 vs tc
On 09/22/14 21:36, John Fastabend wrote:
n-tuple has some deficiencies,
- its not possible to get the capabilities to learn what
fields are supported by the device, what actions, etc.
- its ioctl based so we have to poll the device
- only supports a single table, where w
On 09/22/14 03:53, Jiri Pirko wrote:
Jamal, would you please give us some examples on how to use tc to work
with flows? I have a feeling that you see something other people does not.
I will be a little verbose so as to avoid knowledge assumption.
Lets talk about tc classifier/action subsystem
On 09/20/14 07:51, Thomas Graf wrote:
I fail to see the connection. You can use switch vendor SDK no matter
how we define the kernel APIs. They already exist and have been
designed in a way to be completely indepenedent from the kernel.
Are you referring to vendor specific decisions in user spa
On 09/20/14 07:01, Thomas Graf wrote:
Nothing speaks against having such a tc classifier. In fact, having
the interface consist of only an embedded Netlink attribute structure
would allow for such a classifier in a very straight forward way.
That doesn't mean everybody should be forced to use t
On 09/20/14 04:10, Scott Feldman wrote:
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu wrote:
Existing rtnetlink isn’t available to swdev without some kind of snooping the
echoes from the various kernel components
(bridge, fib, etc).
You have made this claim before Scott and I am still not f
On 09/20/14 04:17, Jiri Pirko wrote:
Yes, that I say. It is needed for flow manipulation, because such api does
not exist.
Come on Jiri!
The ovs guys are against this and now no *api exists*?
Write a 15 tuple classifier tc classifier and use it. I will be more
than happy to help you. I will ge
On 09/19/14 18:12, John Fastabend wrote:
On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
On 09/19/14 11:49, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
Is this just a temporary test tool? Otherwise i dont see reason
for its existence (or the API that it
On 09/19/14 11:49, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
Is this just a temporary test tool? Otherwise i dont see reason
for its existence (or the API that it feeds on).
Please read the conversation I had with Pravin and Jesse in v1 thread.
Long sto
On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using generic Netlink.
Example userspace utility is here:
https://github.com/jpirko/switchdev
Is this just a temporary test tool? Otherwise i dont see reason
for its existence (or the API that it feeds on).
cheers,
jamal
_
On 09/05/14 03:02, Scott Feldman wrote:
On Thu, Sep 04, 2014 at 09:30:45AM -0700, Scott Feldman wrote:
Correct, for the particular switch implementation we’re working with.
Do you have L2/3 working with this interface on said switch?
I am interested.
cheers,
jamal
___
On 09/03/14 17:59, Pravin Shelar wrote:
Both of us are saying same thing.
What I meant was for OVS use-case, where OVS wants to use offload for
switching flows, vswitchd userspace process can program HW offload
using kernel HW offload APIs directly from userspace, rather than
going through OVS k
On 09/03/14 14:41, Pravin Shelar wrote:
On Wed, Sep 3, 2014 at 2:24 AM, Jiri Pirko wrote:
HW offload API should be separate from OVS module.
The above part i agree with. Infact it is very odd that it seems
hard to get this point across ;->
This has following
advantages.
1. It can be manag
On 09/03/14 11:20, John Fastabend wrote:
Also I have some filters that can match on offset/length/mask
tuples. As far as I can tell this is going to have to be yet
another interface? Or would it be worth the effort to define
the flow key more generically. My initial guess is I'll just
write a se
On 09/01/14 16:28, Jiri Pirko wrote:
Jamal, please be ensured that no one I know of is against future
different classifiers.
Ok, glad to hear that.
The patches and/or some of the discussion were not projecting that
view. Even for the flow case, I am pretty sure we are going to
need a few iter
On 09/01/14 04:13, Simon Horman wrote:
On Fri, Aug 29, 2014 at 10:20:55AM -0400, Jamal Hadi Salim wrote:
I actually have no issues with whatever classifier someone decides
to use. To each their poison. But I do take issue mandating the
specified classifer it as THE CLASSIFIER as in this case
On 08/26/14 16:54, Thomas Graf wrote:
On 08/26/14 at 01:13pm, Alexei Starovoitov wrote:
I think it's important distinction. In-kernel OVS is not OF.
It's a networking function that has hard-coded packet parser,
N-tuple match and programmable actions.
There were times when HW vendors were using O
On 08/26/14 11:22, Jiri Pirko wrote:
I do not think that really matters. Phase one is flows. After that we
can focus on l2/l3. If we would be able to fit in in flows (some drivers
may), then ok. If not, we extend the api with couple of more l2/l3
related ndos. I see no problem there.
Well, it
On 08/26/14 11:01, Scott Feldman wrote:
I don’t see it that way. I believe sw_flow can be the intermediary
representation to span flow-based and non-flow-based HW,
and from flow-based world and traditional l2/l3 world.
Is there more magic to this than what Thomas just presented in this
On 08/26/14 10:06, Jiri Pirko wrote:
Yes. Flows are phase one. The api will be extended in for whatever is
needed for l2/l3 as you said. Also I see a possibility to implement the
l2/l3 use case with flows as well.
And as a note: This is where i have the disagreement.
It is good there is acknow
On 08/25/14 18:50, Thomas Graf wrote:
On 08/25/14 at 12:15pm, Jamal Hadi Salim wrote:
On 08/25/14 10:17, Thomas Graf wrote:
I dont think we have a problem handling any of this today.
Yes we do. It's restricted to L2 and we can't extend it easily
It is restricted to L2 becaus
?" And if the answer is negative
they simply dont show up;->
On 08/25/14 at 12:48pm, Jamal Hadi Salim wrote:
On 08/25/14 10:54, Thomas Graf wrote:
I would argue that swflow is a superset of a Netlink route. It
may infact be very useful to extend the API with something that
un
On 08/25/14 10:54, Thomas Graf wrote:
On 08/24/14 at 11:15am, Jamal Hadi Salim wrote:
Let's keep vendors out of this discussion.
The API is from a vendor. It is clearly labelled as an OF API.
It covers well abstracting that vendors SDK to enable OF. That
is relevant info.
If it cover
On 08/25/14 10:17, Thomas Graf wrote:
On 08/25/14 at 09:53am, Jamal Hadi Salim wrote:
fdb_add() *is* flow based. At least in my understanding, the whole
point here is to extend the idea of fdb_add() and make it understand
L2-L4 in a more generic way for the most common protocols.
The reason
On 08/24/14 22:42, John Fastabend wrote:
In the L2 case we already have the fdb_add and fdb_del semantics that
are being used today by NICs with embedded switches. And we have a DSA
patch we could dig out of patchwork for those drivers.
Indeed. That is an excellent starting point of something
On 08/24/14 22:24, Scott Feldman wrote:
On Aug 24, 2014, at 8:15 AM, Jamal Hadi Salim wrote:
With respect to focus on L2/L3, I have a pretty *good* hunch someone could
> write a kernel module that gleans from the L2/L3 netlink echoes
already flying
around and translates to sw_flows
On 08/24/14 07:12, Thomas Graf wrote:
On 08/23/14 at 09:53pm, Jamal Hadi Salim wrote:
I get what you are saying but I don't see that to be the case here. I
don't see how this series proposes the OVS case as *the* interface.
The focus of the patches is on offloading flows (uses
On 08/22/14 18:53, Scott Feldman wrote:
Ok, Scott - now i have looked at the patches on the plane and i am
still not convinced ;->
The intent is to use openvswitch.ko’s struct sw_flow to program hardware via the
ndo_swdev_flow_* ops, but otherwise be independent of OVS. So the upper layer
of
On 08/21/14 13:05, Florian Fainelli wrote:
2014-08-21 9:18 GMT-07:00 Jiri Pirko :
The goal of this is to provide a possibility to suport various switch
chips. Drivers should implement relevant ndos to do so. Now there is a
couple of ndos defines:
- for getting physical switch id is in place.
- f
On 03/27/14 08:00, Thomas Graf wrote:
It seems like we reached pretty good consensus on the model. What
remaining issues do you see with the port model proposed in v2?
Are we really following the same thread?
I dont see any rallying behind Jiri's approach from the
other folks who have their o
On 03/27/14 07:02, Thomas Graf wrote:
On 03/27/14 at 06:27am, Jamal Hadi Salim wrote:
There is definitely need beyond an ndo that is capable of
adding flows. You mention routes. Another example would be
devices capable of offloading iptables & nft rules.
nod.
But wouldn't yo
On 03/27/14 03:21, Jiri Pirko wrote:
Wed, Mar 26, 2014 at 10:44:31PM CET, j...@mojatatu.com wrote:
Well, I think there are 2 main models to be considered:
1. OSV-like model, where everything is flows and that is the OneWay(tm)
mode you mentioned :)
2. clasic switch setting-like model where
Jiri,
The flow extensions may be distracting - note there are many
tables (L3, L2, etc) in such chips not just ACLs. And there's likely no
OneWay(tm) to add a flow. My view is probably to solve or reach an
agreement on the ports. Then resolve the different tables control/data
exposure.
On the swi
On 12-12-11 10:14 PM, Tom Herbert wrote:
This patch adds ipv6 set action functionality. It allows to change
traffic class, flow label, hop-limit, ipv6 source and destination
address fields.
I have to wonder about these patches and the underlying design
direction. Aren't these sort of things an
On Sun, 2012-04-22 at 08:22 -0700, Stephen Hemminger wrote:
> STT isn't really doing TCP, it just lying and pretending to be
> TCP to allow TSO to work! There is no packet ordering, sequence
> numbers or any real transport layer.
True. It is a nice engineering hack but even as a protocol enhance
Jesse,
I empathize with effort youve put in, i really do; youve
already created the messaging from user space to kernel
and dammit it works; however, i dont agree with your reasoning.
The classifier action code is _exactly_ the same infrastructure.
The user space API/messaging already exists. If
On Mon, 2011-11-28 at 10:44 -0800, Justin Pettit wrote:
> I realize you chair an IETF standard with overlapping goals with
> OpenFlow (ForCES), so you may have strong opinions about its design.
Yes, I do have strong opinions not really related to ForCES more towards
Linux. If i was to put ForCES
On Mon, 2011-11-28 at 10:34 -0800, Justin Pettit wrote:
> On Nov 25, 2011, at 5:11 PM, Jamal Hadi Salim wrote:
>
> Are you talking about ASICs on NICs?
I am indifferent - looking at it entirely from a control
perspective. i.e if i do "ip link blah down" on a port
i want tha
On Mon, 2011-11-28 at 08:01 -0800, Ben Pfaff wrote:
> Regarding OpenFlow rate limiting, in addition to Martin's response, Open
> vSwitch has implemented controller rate limiting since day one. It is
> documented in ovs-vswitchd.conf.db(5):
Ok, I think thats a good start. My experience says just
On Mon, 2011-11-28 at 07:27 -0800, Martin Casado wrote:
> This is a common misunderstanding about OpenFlow. It does not require
> the first packet of each flow to go to the controller.
I am reading this to mean that the switch CPU will resolve things?
Typically those tend to be tiny cpus.
>
On Mon, 2011-11-28 at 13:54 +, Fischer, Anna wrote:
> Yes, I mentioned this months ago, and I am surprised this critical
> issue has never been picked up on and addressed. With a flaw like
> this there is no chance this component can be used in any serious
> virtualization deployment where
On Mon, 2011-11-28 at 21:04 +0800, Herbert Xu wrote:
> You're right, a new classifier for the hash table would be the
> best option.
>
> > I cant find one - you may. After staring at the code, I am also now
> > questioning if the existing bridge code couldnt have been re-used with
> > some small
On Fri, 2011-11-25 at 12:20 -0800, Jesse Gross wrote:
> The flow classifier isn't really designed to do rule lookup in the way
> that OpenFlow/Open vSwitch does, since it's more about choosing which
> fields are considered significant to the flow. I'm sure that it could
> be extended in some way
On Fri, 2011-11-25 at 11:52 -0800, Justin Pettit wrote:
> On Nov 24, 2011, at 9:20 PM, Stephen Hemminger wrote:
>
> A big difficulty is finding an appropriate hardware abstraction. I've worked
> on porting
> Open vSwitch to a few different vendors' switching ASICs, and they've all
> looked qu
On Wed, 2011-11-23 at 08:05 -0800, John Fastabend wrote:
> > Makes sense in most cases. If you have a lot of flow setup/teardown
> > it may harm.
>
> We could have a CONFIG option to always do locking in some
> cases if thats not too ugly.
What i mean is RCU is useful when you have a substantial
On Wed, 2011-11-23 at 15:15 +0100, Eric Dumazet wrote:
>
> Or, we could stick documentation in kernel (Documentation/network/...),
> so that we give credit to contributors to this essential part of the
> network stack.
>
That would work - but i dont know how many "users" read
Documentation/netw
On Wed, 2011-11-23 at 13:55 +0100, Eric Dumazet wrote:
> Currently thinking about it. I was also waiting Tom Herbert BQL patches.
Excellent. I can test when you have something.
> Several people are interested, and John Fastabend told me he plans to :
>
> (1) rcu'ify classifiers/actions as need
On Tue, 2011-11-22 at 18:30 -0800, John Fastabend wrote:
> He is pushing and popping entire tags off 802.1Q for now but
> you can easily imagine MPLS tags and all sorts of other things
> people will _need_.
Lots of packet munging already happening with actions.
We can pedit/nat/iptables/checksum
On Tue, 2011-11-22 at 15:11 -0800, Jesse Gross wrote:
> As you mention, one of the biggest benefits of Open vSwitch is how
> simple the kernel portions are (it's less than 6000 lines).
I said that was the reason _you_ were using to justify things
and i argue that is not accurate.
You will be a
50 matches
Mail list logo
