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&#
f 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.
How would one allow for a bypass to create tables (a write command)
but not to write to said tables? li
t the above anyways.
We could port the ethtool ops over to the new interface to
simplify drivers.
Indeed.
cheers,
jamal
.John
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
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
you are saying) but i dont think there is
any other kernel subsystem that has this challenge.
Note: i am pointing to fdb only because it carries the concept of "put
this in hardware and/or software". I agree the fdb maybe reasonably
simpler.
cheers,
jamal
__
not use s/ware.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
following.
Why do we need to echo things to get FDB or FIB to work? device ops for
FDB offload for example already exist. I think they need to be
revamped, but that consensus can be reasonably reached. Why do we
need this flow api for such activities?
cheers,
jamal
shouldnt allow for such loopholes. This is why/how TOE never made it
in the kernel.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
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
tool, yes it is for testing purposes now. ovs daemon
will use directly switchdev genl api.
I hope I cleared this out.
It is - thanks Jiri.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
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
kernel module. If user wants to use some other tool,
then the tool can use same kernel HW offload APIs.
Ok, sorry, you are right - we are saying the same thing.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman
ency;-> So,
I strongly disagree. You may need to go backwards and look at
views expressed on this (other than emails - theres slideware).
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
ite a separate interface. I think this is what Jamal referred
to as another "classifier".
Exactly. I have more complex classifiers as stated earlier.
I am afraid these patches again are not satisfying that need.
In any case - we are taking a different tact than these patches
do and ho
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
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
roach this driver has taken.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
this thread?
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
acknowledgement you are handling flows for now.
Or whatever tuples you defined as "flow". I dont think L2 or 3 fit
in that. If thats not what you are saying then we are in agreement.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openv
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
world.
cheers,
jamal
.John
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
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
res. And u32 is very implementable
in hardware.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
.
What do you think?
I thought we had concluded that DSA was a good path forward? Or maybe
at this stage we need to have several alternative approaches
and we eventually converge?
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http
their own code and way of approaching things.
I am hoping we dont continue with the split that is there
already.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
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
lieve it
is a longer discussion needed than the port resolving.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
n the switchdev - You are still exposing it; do you expect these
things to be created from user space? Probably thats one approach, but
I would suspect the majority would result in the driver itself creating
these devices after discovering the resources from the control
interfaces (PCIE etc).
cheers,
g things (bridge level)
as i was mentioning to you tc action is the right abstraction. There is
nothing they do that cant be done at that level. I am hoping that i will
get time/resources to illustrate a purely standard kernel level approach.
cheer
te reasons
and could be used by STT (I think the claim was no hardware
does USO);->
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
\
action ip set 10.0.0.1
action checksum \
action blah \
flowid :1
Yes, that uses the same API you just used to set the policer.
cheers,
jamal
On Sun, 2011-12-04 at 16:57 -0800, Justin Pettit wrote:
> Mike Bursell pointed out that our policer only works on IPv4
> traffic--and specifically no
.
cheers,
jamal
On Fri, 2011-12-02 at 15:30 -0800, Jesse Gross wrote:
>
> I completely agree with the desire to share code where there's overlap
> and it makes sense (I was actually just working on some refactoring to
> increase code reuse before this).
>
> I think one of the ke
(time flies) i compared against iptables, the tc flow
setup/teardown was pretty consistent regardless of table size
relatively speaking.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Tue, 2011-11-29 at 22:18 -0800, Jesse Gross wrote:
> As Jamal alluded to above, it's
> actually the bridge code which is more conceptually similar.
Either you misread what i said or i miscommunicated.
The exact similarity is in classifier action in the datapath.
The bridge, as
hich Eric is hopefully
going to work on now that bql is in? classifier/action happens way
before that.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Tue, 2011-11-29 at 22:25 -0800, Jesse Gross wrote:
> Hi Herbert and Jamal (and everyone else),
>
> Sorry about starting yet another thread but the other one went in so
> many directions that I think a lot of things got lost in it.
Good idea ;->
> As I
> mentioned befor
ment is so high on that wave nobody will listen ;->
The only reason i keep bringing up openflow is because your architecture
in the minimal evolved from there (the fact you deal with flows and
actions and switches). I could stop talking about it if it is
offensive ;->
cheers,
jamal
_
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
ontroller.
You dont have multiple queues (given a single TCP socket) and config,
events, and exception packets are all shared in one queue.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
ould be problematic imo if the architecture doesnt
allow prioritization of some form towards the controller.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
er where
there is a single (TCP) socket.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
g
> DoS opportunities that exist in the patch as is.
>
> In particular, the whole design principle of punting all new
> flows to user-space is an excellent way of attacking the system.
Indeed this is an issue with openflow in general.
The general solution is to rate limit how m
On Sun, 2011-11-27 at 20:34 +0100, Lennert Buytenhek wrote:
> On Thu, Nov 24, 2011 at 08:19:39AM -0500, Jamal Hadi Salim wrote:
> There's a bunch of features that the hardware supports that have no
> analog in the Linux networking stack (e.g. port mirroring a non-CPU
> port t
granularity there).
> As a result, we haven't seen a need to improve support for policing.
HTB's metering algorithm was essentially originally ripped off the
policer action; probably better off for TCP to use shaping hence the
results you are observing.
cheers,
jamal
_
Stephen
> mentioned about the bridge, many of these components are already
> fairly complex and combining more functionality into them isn't always
> a win.
I think the bridge started on a bad foot for not properly integrating
with Vlans and ti
> vendors use to get their OpenFlow support) and are now shipping.
>
> We're always open to discussing ways that we can improve this interfaces,
> too, of course!
Make these vendor switches work with plain Linux. The Intel folks are
producing interfaces
Hrm. I forgot about the flow classifier - it may be what the openflow
folks need. It is more friendly for the well defined tuples than u32.
But what do you mean "refactor"? I can already use this classifier
and attach actions to set policy in the kernel.
cheers,
jamal
On Fri, 2011-1
On Thu, 2011-11-24 at 21:20 -0800, Stephen Hemminger wrote:
> On Thu, 24 Nov 2011 17:30:33 -0500
> jamal wrote:
>
> > Can you explain why you couldnt use the current bridge code (likely with
> > some mods)? I can see you want to isolate the VMs via the virtual ports;
&g
> largely new code that is geared towards this particular model so it
> seems better not to add to the complexity of existing components if at
> all possible.
I am still not seeing how this could not be done without the
infrastructure that exists. Granted, the user space brains - thats whe
other thing, is you match every flow on the specific
virtual port - this may be design intent but it appears
very inflexible.
cheers,
jamal
On Wed, 2011-11-23 at 18:34 -0800, Justin Pettit wrote:
> On Nov 22, 2011, at 5:45 PM, Jamal Hadi Salim wrote:
>
> > BTW, you _are using some of
after the queue is
> already selected. At this point you can't send it to
> a higher/lower priority queue.
>
Still blanking out - will wait for the code to comment.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
" read
Documentation/network/
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
s
Where does config for the hardware happen from?
> (3) mq and mqprio call root qdisc and run a pass over classifiers
> actions possibly resetting queue_mapping.
It seems to make sense - but I will wait and see to have better
understanding.
cheers,
jamal
_
t you get a different domain name.
tc.org or something along those lines.
Start aggregating documentation that is validated to be working. There's
a lot of "opinions" out there instead of facts.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
re - sometimes a little too much
with differing "opinions" (lartc that Herbert pointed to is a good
starting point); but googling also helps.
Unfortunately, sometimes the people who understand stuff have no
motivation to do docs.
cheers,
jamal
__
On Wed, 2011-11-23 at 15:54 +0800, Herbert Xu wrote:
> I mostly agree with Jamal. As far as the concept of a policy
> lookup cache goes (which appears to be at the core of OVS), this
> almost fits exactly onto a u32 hash table. All that would be needed
> is to add the tail end of
ld flush
> out that TODO in act_mirred, and get us an mq_ingress among
> other things.
The packet redirect to user space is achieveable in many other
ways, thats why it was not added.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
hedulers and will
have to replicate things we provide. And they all go into this
monolithic code because it is "simpler".
Is there anything we do that makes it hard for you to use the
infrastructure provided? Is there anything you do that we cant
provide via the classifier-action-scheduler inf
Reading your website - it seems you indicate the code to be portable
across other platforms. That is a noble reason - but i dont think
it is good enough a reason in my opinion to have your own
replicated infrastructure on top of Linux.
cheers,
jamal
On Mon, 2011-11-21 at 07:20 -0500, jamal
- but in a few
months you'll need one more then another action and another and
you'll keep adding to your infrastructure.
cheers,
jamal
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
66 matches
Mail list logo
