* Ethan Jackson (et...@nicira.com) wrote:
> It will be garbage collected later when the bridge notices a port in
> the datapath which it doesn't know about.
OK, thanks for clarifying.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailma
It will be garbage collected later when the bridge notices a port in
the datapath which it doesn't know about.
On Thu, Apr 12, 2012 at 19:01, Chris Wright wrote:
> * Ethan Jackson (et...@nicira.com) wrote:
>> > Is this part correct when !may_port_action?
>>
>> Seems correct to me, wether or not w
On Thu, Apr 12, 2012 at 06:35:53PM -0700, Jesse Gross wrote:
> On Thu, Apr 12, 2012 at 5:53 PM, Simon Horman wrote:
> > On Thu, Apr 12, 2012 at 05:45:33PM -0700, Jesse Gross wrote:
> >> On Thu, Apr 12, 2012 at 12:36 AM, Simon Horman wrote:
> >> > The STT protocol allows a VLAN TCI to be passed as
* Ethan Jackson (et...@nicira.com) wrote:
> > Is this part correct when !may_port_action?
>
> Seems correct to me, wether or not we can delete the port from
> ofproto, we can go ahead and clean up the interface's netdev. The
> ofproto port will be cleaned up later. I may be missing something
> t
On Thu, Apr 12, 2012 at 5:53 PM, Simon Horman wrote:
> On Thu, Apr 12, 2012 at 05:45:33PM -0700, Jesse Gross wrote:
>> On Thu, Apr 12, 2012 at 12:36 AM, Simon Horman wrote:
>> > The STT protocol allows a VLAN TCI to be passed as part of the
>> > STT header. It seems appropriate to pass this TCI
On Thu, Apr 12, 2012 at 05:45:33PM -0700, Jesse Gross wrote:
> On Thu, Apr 12, 2012 at 12:36 AM, Simon Horman wrote:
> > The STT protocol allows a VLAN TCI to be passed as part of the
> > STT header. It seems appropriate to pass this TCI to ovs_tnl_rcv()
> > and for other tunneling protocols to p
> Is this part correct when !may_port_action?
Seems correct to me, wether or not we can delete the port from
ofproto, we can go ahead and clean up the interface's netdev. The
ofproto port will be cleaned up later. I may be missing something
though, could you please give a bit more detail about w
On Thu, Apr 12, 2012 at 12:36 AM, Simon Horman wrote:
> The STT protocol allows a VLAN TCI to be passed as part of the
> STT header. It seems appropriate to pass this TCI to ovs_tnl_rcv()
> and for other tunneling protocols to pass 0 to retain their existing
> behaviour.
>
> Signed-off-by: Simon
* Ethan Jackson (et...@nicira.com) wrote:
> @@ -1039,7 +1079,8 @@ add_del_bridges(const struct ovsrec_open_vswitch *cfg)
> * port already belongs to a different datapath, so we must do all port
> * deletions before any port additions. */
> static void
> -bridge_del_ofproto_ports(struct bridge
On Thu, Apr 12, 2012 at 04:58:03PM -0700, Ansis Atteka wrote:
> On Wed, Apr 11, 2012 at 9:51 AM, Ben Pfaff wrote:
>
> > On Tue, Apr 10, 2012 at 02:32:48PM -0700, Ansis Atteka wrote:
> > > Add documentation on how to use OVS integration
> > > with the upcoming Libvirt 0.9.11 release.
> >
> > Thank
On Wed, Apr 11, 2012 at 9:51 AM, Ben Pfaff wrote:
> On Tue, Apr 10, 2012 at 02:32:48PM -0700, Ansis Atteka wrote:
> > Add documentation on how to use OVS integration
> > with the upcoming Libvirt 0.9.11 release.
>
> Thanks for writing this!
>
> Here, you might consider adding something like "or y
This is cleaner than using the need_reconfigure flag to guarantee at
least one port modification so I've folded it in.
I'll merge this when I've had a chance to test it.
Ethan
On Thu, Apr 12, 2012 at 16:31, Ben Pfaff wrote:
> On Wed, Apr 11, 2012 at 01:04:37PM -0700, Ethan Jackson wrote:
>> In
On Wed, Apr 11, 2012 at 01:04:37PM -0700, Ethan Jackson wrote:
> In some datapaths, adding or deleting OpenFlow ports can take quite
> a bit of time. If there are lots of OpenFlow ports which needed to
> be added in a run loop, this can cause Open vSwitch to lock up and
> stop setting up flows whi
In some datapaths, adding or deleting OpenFlow ports can take quite
a bit of time. If there are lots of OpenFlow ports which needed to
be added in a run loop, this can cause Open vSwitch to lock up and
stop setting up flows while trying to catch up. This patch lessons
the severity of the problem
On Thu, Apr 12, 2012 at 03:51:11PM -0700, Ethan Jackson wrote:
> > Seems reasonable.
> >
> > I'm not sure that it's worth logging at all; maybe it should go in the
> > database (is it there already? not obviously).
>
> Putting it the database is probably the right thing to do. I don't
> have time
> Seems reasonable.
>
> I'm not sure that it's worth logging at all; maybe it should go in the
> database (is it there already? not obviously).
Putting it the database is probably the right thing to do. I don't
have time for it at the moment though. I'll add it to my list of
things to get around
On Wed, Apr 11, 2012 at 12:10:13AM -0700, Ethan Jackson wrote:
> In some datapaths, adding or deleting OpenFlow ports can take quite
> a bit of time. If there are lots of OpenFlow ports which needed to
> be added in a run loop, this can cause Open vSwitch to lock up and
> stop setting up flows whi
Thanks, I fixed that typo in two places and I'll push this series soon.
On Wed, Apr 11, 2012 at 11:33:24AM -0700, Ethan Jackson wrote:
> Yay! We've needed this for a while. Looks good.
>
> s/columsn/columns
>
> Ethan
>
> On Tue, Mar 27, 2012 at 17:00, Ben Pfaff wrote:
> > Signed-off-by: Ben
Ethan, thanks, I removed it.
Reid, thanks for the comment. I guess I don't really care about that
test code, it's more or less disposable.
Thanks,
Ben.
On Wed, Apr 11, 2012 at 11:23:40AM -0700, Ethan Jackson wrote:
> There's some trailing whitespace in the Python.
>
> Otherwise looks good to
On Wed, Apr 04, 2012 at 01:47:58PM -0700, Ethan Jackson wrote:
> > + seqno = idl.change_seqno # Sequence number when we last processed
> > the db
>
> Does it make sense to initialize seqno to None so we're guaranteed to
> run through the database initially? Looking at ovs-xapi-sync it uses
This hook is based on a hook of the same name provided by UDP. It provides
a way for to receive packets that have a TCP header and treat them in some
alternate way.
It is intended to be used by an implementation of the STT tunneling
protocol within Open vSwtich's datapath. A prototype of such an
On Thu, Apr 12, 2012 at 11:05:28AM +0200, Eric Dumazet wrote:
> Most machines dont use UDP encapsulation (L2TP)
>
> Adds a static_key so that udp_queue_rcv_skb() doesnt have to perform a
> test if L2TP never setup the encap_rcv on a socket.
>
> Idea of this patch came after Simon Horman proposal
Thanks a lot. I somehow missed that file ;)
Best Regards,
Nikhil
On Thu, Apr 12, 2012 at 7:07 PM, Kyle Mestery (kmestery) wrote:
> Bringing the list back onto this thread, accidentally removed during last
> reply.
>
> On Apr 12, 2012, at 8:35 AM, wrote:
> > On Apr 12, 2012, at 8:31 AM, Nikhil
Bringing the list back onto this thread, accidentally removed during last reply.
On Apr 12, 2012, at 8:35 AM, wrote:
> On Apr 12, 2012, at 8:31 AM, Nikhil wrote:
>>
>> Thanks a lot for you reply. I cloned ovs-vxlan from GIT, and I am able to
>> see 'remotes/origin/ovs-vxlan' branch. My query i
On Apr 12, 2012, at 3:31 AM, Nikhil wrote:
>
> Hello,
>
> I would like to setup Open vSwitch with VxLAN tunneling. Could you kindly let
> me know how should I apply patches to open vSwitch. I downloaded mestery's
> https://github.com/mestery/ovs-vxlan.git. Saw changes in datapath folder for
>
On Thu, Apr 12, 2012 at 10:20:29AM +0200, Eric Dumazet wrote:
> On Thu, 2012-04-12 at 16:42 +0900, Simon Horman wrote:
> > This hook is based on a hook of the same name provided by UDP. It provides
> > a way for to receive packets that have a TCP header and treat them in some
> > alternate way.
>
On Thu, 2012-04-12 at 11:05 +0200, Eric Dumazet wrote:
> If static_key is not yet enabled, the fast path does a single JMP .
>
> When static_key is enabled, JMP destination is patched to reach the real
> encap_type/encap_rcv logic, possibly adding cache misses.
Small note Simon,
The jump trick
Most machines dont use UDP encapsulation (L2TP)
Adds a static_key so that udp_queue_rcv_skb() doesnt have to perform a
test if L2TP never setup the encap_rcv on a socket.
Idea of this patch came after Simon Horman proposal to add a hook on TCP
as well.
If static_key is not yet enabled, the fast
Hello,
I would like to setup Open vSwitch with VxLAN tunneling. Could you kindly
let me know how should I apply patches to open vSwitch. I downloaded
mestery's https://github.com/mestery/ovs-vxlan.git. Saw changes in datapath
folder for vport-vxlan.c and vport-vxlan.h.
Could you let me know the p
On Thu, 2012-04-12 at 16:42 +0900, Simon Horman wrote:
> This hook is based on a hook of the same name provided by UDP. It provides
> a way for to receive packets that have a TCP header and treat them in some
> alternate way.
>
> It is intended to be used by an implementation of the STT tunneling
This hook is based on a hook of the same name provided by UDP. It provides
a way for to receive packets that have a TCP header and treat them in some
alternate way.
It is intended to be used by an implementation of the STT tunneling
protocol within Open vSwtich's datapath. A prototype of such an
This is a not yet well exercised implementation of STT intended for review,
I am sure there are numerous areas that need improvement.
In particular:
- The transmit path's generation of partial checksums needs to be tested
- The VLAN stripping code needs to be excercised
- The code needs to be exer
The STT protocol allows a VLAN TCI to be passed as part of the
STT header. It seems appropriate to pass this TCI to ovs_tnl_rcv()
and for other tunneling protocols to pass 0 to retain their existing
behaviour.
Signed-off-by: Simon Horman
---
datapath/tunnel.c |5 +++--
datapath/tunnel
This series contains a prototype implementation of STT for Open vSwitch.
This series consists of two patches:
* datapath: tunneling: Allow vlan_tci to be passed
This patch make minor changes to the generic
tunneling code which seem to be necessary for STT.
* tunnelling: stt: Prototype Imple
34 matches
Mail list logo
