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 that to work with zero
On Nov 25, 2011, at 5:11 PM, Jamal Hadi Salim 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 quite
>> different from each other. Even within a vendor,
Not sure how Openvswitch implementation relates to Openflow specification.
The short answer is that Open vSwitch serves as one of the standard
reference implementations for OpenFlow (in fact, the primary developers
of Open vSwitch were some of the original designers of OpenFlow).
Multiple ha
Not sure how Openvswitch implementation relates to Openflow specification.
There are a few switches supporting Openflow already:
http://www.openflow.org/wp/switch-nec/
http://www-03.ibm.com/systems/x/options/networking/bnt8264/index.html
The standard(s) are here:
http://www.openflow.org/wp/
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 Fri, Nov 25, 2011 at 3:34 AM, jamal wrote:
>
> 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.
The flow classifier isn't really designed to do rule lookup in the way
that OpenFlow/Open vSwitch does, s
On Thu, Nov 24, 2011 at 10:18 PM, Eric Dumazet wrote:
> Le jeudi 24 novembre 2011 à 21:20 -0800, Stephen Hemminger a écrit :
>
>> The problem is that there are two flow classifiers, one in OpenVswitch
>> in the kernel, and the other in the user space flow manager. I think the
>> issue is that the
On Nov 24, 2011, at 9:20 PM, Stephen Hemminger wrote:
>> This can be achieved easily with zero changes to the kernel code.
>> You need to have default filters that redirect flows to user space
>> when you fail to match.
>
> Actually, this is what puts me off on the current implementation.
> I wou
On Thu, Nov 24, 2011 at 9:20 PM, Stephen Hemminger
wrote:
> On Thu, 24 Nov 2011 17:30:33 -0500
> jamal wrote:
>> On Thu, 2011-11-24 at 12:10 -0800, Jesse Gross wrote:
>> > * Userspace interfaces: One of the difficulties of having a
>> > specialized, exact match flow lookup engine is maintaining
On Fri, 25 Nov 2011 06:24:36 -0500
jamal wrote:
> Most hardware bridges out there support all different modes:
> You can have learning in the hardware or defer it to user/control plane
> by setting some flags. You can have broadcasting done in hardware or
> defer to user space.
> The mods i was
Le vendredi 25 novembre 2011 à 06:34 -0500, jamal a écrit :
> 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
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-11-25 at 07:3
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;
> > maybe even vlans on the
Le vendredi 25 novembre 2011 à 01:25 -0500, David Miller a écrit :
> From: Eric Dumazet
> Date: Fri, 25 Nov 2011 07:18:03 +0100
>
> > Le jeudi 24 novembre 2011 à 21:20 -0800, Stephen Hemminger a écrit :
> >
> >> The problem is that there are two flow classifiers, one in OpenVswitch
> >> in the k
From: Eric Dumazet
Date: Fri, 25 Nov 2011 07:18:03 +0100
> Le jeudi 24 novembre 2011 à 21:20 -0800, Stephen Hemminger a écrit :
>
>> The problem is that there are two flow classifiers, one in OpenVswitch
>> in the kernel, and the other in the user space flow manager. I think the
>> issue is that
Le jeudi 24 novembre 2011 à 21:20 -0800, Stephen Hemminger a écrit :
> The problem is that there are two flow classifiers, one in OpenVswitch
> in the kernel, and the other in the user space flow manager. I think the
> issue is that the two have different code.
We have kind of same duplication in
On Thu, 24 Nov 2011 17:30:33 -0500
jamal wrote:
> Jesse,
>
> I am going to try and respond to your comments below.
>
> On Thu, 2011-11-24 at 12:10 -0800, Jesse Gross wrote:
>
> >
> > * Switching infrastructure: As the name implies, Open vSwitch is
> > intended to be a network switch, focuse
Jesse,
I am going to try and respond to your comments below.
On Thu, 2011-11-24 at 12:10 -0800, Jesse Gross wrote:
>
> * Switching infrastructure: As the name implies, Open vSwitch is
> intended to be a network switch, focused on
> virtualization/OpenFlow/software defined networking. This me
I realized that since Open vSwitch is so userspace-centric some of the
design considerations might not be apparent from the kernel code
alone. I did a poor job of explaining the larger picture which has
lead to some misconceptions, so I thought it would be helpful if I
gave a short overview.
One
20 matches
Mail list logo
