Hi all,
we have finally found the time to finish work on this patch. We have
addressed all the issues that were mentioned in the previous mails, plus
some more that showed up later. We now pass all unit tests on both Linux
and FreeBSD and we can more confidently offer the patch to your
attent
On Thu, Sep 27, 2012 at 5:44 PM, Simon Horman wrote:
> On Thu, Sep 27, 2012 at 04:45:22PM -0700, Jesse Gross wrote:
> > On Thu, Sep 27, 2012 at 12:05 PM, ravi kerur wrote:
> > > On Thu, Sep 27, 2012 at 11:16 AM, Jesse Gross
> wrote:
> > >> On Thu, Sep 27, 2012 at 9:26 AM, Ben Pfaff wrote:
> >
On Fri, Sep 28, 2012 at 03:07:08PM +0900, Simon Horman wrote:
> Signed-off-by: Simon Horman
Applied, thanks!
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Fri, Sep 28, 2012 at 12:49:16PM +0200, Giuseppe Lettieri wrote:
> we have finally found the time to finish work on this patch. We have
> addressed all the issues that were mentioned in the previous mails,
> plus some more that showed up later. We now pass all unit tests on
> both Linux and FreeB
On Fri, Sep 28, 2012 at 09:23:01AM -0700, Ben Pfaff wrote:
> I think that there are now synchronization issues in vlog. The
> vlog_write_file() implementation assumes a single-threaded model
> (worker_request() isn't thread-safe). We could introduce per-thread
> state so that only the main thread
On Fri, Sep 28, 2012 at 02:59:10PM +0900, Simon Horman wrote:
> Based heavily on work by Isaku Yamahata
>
> Cc: Isaku Yamahata
> Signed-off-by: Simon Horman
Thanks, I added a test and tweaked the documentation and applied this
to master.
___
dev mail
This is a port of the kernel tunneling logic to userspace, taking
advantage of the outer header information in the flow. It logically
fits in after Kyle's tunnel kernel patch and before Justin's single
datapath work. I expect that the final patch in this series will
be replaced by Justin's better
Now that the kernel is supplying information about the outer IP
header for tunneled packets userspace needs to be able to track it
as part of the flow. For the time being this is only used internally
by OVS and not exposed outwards to OpenFlow. As a result, this
threads the information throughout
Now that both the kernel and userspace can handle information about
the tunnel outer headers this adds userspace support for communicating
between the two. At the moment userspace doesn't know how to do
anything with the extra information on receive and will only generate
actions containing tun_id
In order to be able to unit test the tunnel flow setup code we
need to be able to generate netdevs that appear to be like
tunnel devices. This adds a dummy_tunnel netdev with two
differences from the normal dummy devices: the ability to set and
read config and a different type to identify them as
The kernel tunneling code currently needs to handle a large number
of operations when tunnel packets are encapsulated and decapsulated.
Some examples of this are: finding the correct tunnel port on receive,
TTL and ToS inheritance, ECN handling, etc. All of these can be done
on a per-flow basis in
This is a basic set of hooks into the ofproto-dpif code so that
tunneled packets can be have their flows rewritten to reflect the
outward facing view of how ports are laid out. This is far from
being a comprehensive layer and should be replaced once a better
level of indirection is available.
Sig
On Fri, Sep 28, 2012 at 3:49 AM, Giuseppe Lettieri
wrote:
> Hi all,
>
> we have finally found the time to finish work on this patch. We have
> addressed all the issues that were mentioned in the previous mails, plus
> some more that showed up later. We now pass all unit tests on both Linux and
> F
These patches build on the first two patches which Simon Horman sent out in
May to move Open vSwitch towards flow-based tunneling. The first patche adds
a tun_key, deprecating the tun_id member of the ovs_skb_cb struct. This patche
retain compatibilty with existing tunneling, but once the userspace
This is a first pass at providing a tun_key which can be
used as the basis for flow-based tunnelling. The
tun_key includes and replaces the tun_id in both struct
ovs_skb_cb and struct sw_tun_key.
This patch allows all existing tun_id behaviour to still work. Existing
users of tun_id are redirected
Move struct ovs_key_ipv4_tunnel out of struct
sw_flow_key and into struct sw_flow. This allows it to
"float" and be used for matching only when needed.
Modify the matching code in ovs_flow_tbl_lookup() to
match on the tunnel header if it's set.
In particular, I'd like review of the method used for
On Sep 28, 2012, at 1:12 PM, Jesse Gross wrote:
> Now that both the kernel and userspace can handle information about
> the tunnel outer headers this adds userspace support for communicating
> between the two. At the moment userspace doesn't know how to do
> anything with the extra information on
On Fri, Sep 28, 2012 at 11:12:21AM -0700, Jesse Gross wrote:
> Now that the kernel is supplying information about the outer IP
> header for tunneled packets userspace needs to be able to track it
> as part of the flow. For the time being this is only used internally
> by OVS and not exposed outwar
On Thu, Sep 27, 2012 at 8:36 PM, Ben Pfaff wrote:
> On Fri, Sep 28, 2012 at 11:56:47AM +0900, Tadaaki Nagao wrote:
>> In "Re: [ovs-dev] "brctl show" doesn't list attached interfaces",
>> Ben Pfaff wrote:
>> > I see datapaths in brctl show output even without brcompat:
>> >
>> > oot@debian
On Thu, Sep 27, 2012 at 8:18 PM, Tadaaki Nagao wrote:
> Hi,
>
> In "Re: [ovs-dev] "brctl show" doesn't list attached interfaces",
> Jesse Gross wrote:
>> I think it's the opposite problem - that OVS ports aren't appearing in
>> brctl output. There's a bug with namespaces on certain kernels w
On Fri, Sep 28, 2012 at 11:12:22AM -0700, Jesse Gross wrote:
> Now that both the kernel and userspace can handle information about
> the tunnel outer headers this adds userspace support for communicating
> between the two. At the moment userspace doesn't know how to do
> anything with the extra in
On Fri, Sep 28, 2012 at 11:12:23AM -0700, Jesse Gross wrote:
> In order to be able to unit test the tunnel flow setup code we
> need to be able to generate netdevs that appear to be like
> tunnel devices. This adds a dummy_tunnel netdev with two
> differences from the normal dummy devices: the abi
Signed-off-by: Ed Maste
---
As suggested by Ben Pfaff in the 'Threaded userspace datapath' thread.
This looks like a useful utility function refactoring, independent of
any outcome of that discussion.
lib/fatal-signal.c | 4 +---
lib/process.c | 4 +---
lib/signals.c | 4 +---
lib/sock
On Fri, Sep 28, 2012 at 12:54 PM, Ben Pfaff wrote:
> On Fri, Sep 28, 2012 at 11:12:21AM -0700, Jesse Gross wrote:
>> Now that the kernel is supplying information about the outer IP
>> header for tunneled packets userspace needs to be able to track it
>> as part of the flow. For the time being thi
On Fri, Sep 28, 2012 at 11:12:24AM -0700, Jesse Gross wrote:
> The kernel tunneling code currently needs to handle a large number
> of operations when tunnel packets are encapsulated and decapsulated.
> Some examples of this are: finding the correct tunnel port on receive,
> TTL and ToS inheritance
On Fri, Sep 28, 2012 at 1:55 PM, Ben Pfaff wrote:
> On Fri, Sep 28, 2012 at 11:12:22AM -0700, Jesse Gross wrote:
>> Now that both the kernel and userspace can handle information about
>> the tunnel outer headers this adds userspace support for communicating
>> between the two. At the moment users
On Fri, Sep 28, 2012 at 09:06:41PM +, Ed Maste wrote:
> Signed-off-by: Ed Maste
> ---
> As suggested by Ben Pfaff in the 'Threaded userspace datapath' thread.
> This looks like a useful utility function refactoring, independent of
> any outcome of that discussion.
Applied to master, thank you
On Fri, Sep 28, 2012 at 2:18 PM, Ben Pfaff wrote:
> On Fri, Sep 28, 2012 at 11:12:24AM -0700, Jesse Gross wrote:
>> The kernel tunneling code currently needs to handle a large number
>> of operations when tunnel packets are encapsulated and decapsulated.
>> Some examples of this are: finding the c
Cabestan. Layout Simple
Asegúrate de no perderte ninguna oferta, añade ofer...@globalbono.com a tu
lista de contactos.
Si no ves correctamente las imágenes, pulsa [
http://email.globalbono.com/E28092012142809.cfm?WL=1599&WS=208833_8707685&WA=822
] aquí
[ http://email.globalbono.com/Go/index.c
Now that the kernel is supplying information about the outer IP
header for tunneled packets userspace needs to be able to track it
as part of the flow. For the time being this is only used internally
by OVS and not exposed outwards to OpenFlow. As a result, this
threads the information throughout
Now that both the kernel and userspace can handle information about
the tunnel outer headers this adds userspace support for communicating
between the two. At the moment userspace doesn't know how to do
anything with the extra information on receive and will only generate
actions containing tun_id
In order to be able to unit test the tunnel flow setup code we
need to be able to generate netdevs that appear to be like
tunnel devices. This adds a dummy_tunnel netdev with two
differences from the normal dummy devices: the ability to set and
read config and a different type to identify them as
The kernel tunneling code currently needs to handle a large number
of operations when tunnel packets are encapsulated and decapsulated.
Some examples of this are: finding the correct tunnel port on receive,
TTL and ToS inheritance, ECN handling, etc. All of these can be done
on a per-flow basis in
This is a basic set of hooks into the ofproto-dpif code so that
tunneled packets can be have their flows rewritten to reflect the
outward facing view of how ports are laid out. This is far from
being a comprehensive layer and should be replaced once a better
level of indirection is available.
Sig
To me, it was that the existing code mostly worked and had already proved to be
a real performance improvement. This coupled with the limited manpower we could
pour on the project. I understand that turning a single-threaded program into a
multi-threaded one looks scary, and with reason. On the
On Fri, Sep 28, 2012 at 11:59 AM, Kyle Mestery (kmestery)
wrote:
> On Sep 28, 2012, at 1:12 PM, Jesse Gross wrote:
>> Now that both the kernel and userspace can handle information about
>> the tunnel outer headers this adds userspace support for communicating
>> between the two. At the moment use
On Sep 28, 2012, at 5:40 PM, Jesse Gross wrote:
> On Fri, Sep 28, 2012 at 11:59 AM, Kyle Mestery (kmestery)
> wrote:
>> On Sep 28, 2012, at 1:12 PM, Jesse Gross wrote:
>>> Now that both the kernel and userspace can handle information about
>>> the tunnel outer headers this adds userspace support f
On Fri, Sep 28, 2012 at 3:44 PM, Kyle Mestery (kmestery)
wrote:
> On Sep 28, 2012, at 5:40 PM, Jesse Gross wrote:
>> On Fri, Sep 28, 2012 at 11:59 AM, Kyle Mestery (kmestery)
>> wrote:
>>> On Sep 28, 2012, at 1:12 PM, Jesse Gross wrote:
Now that both the kernel and userspace can handle infor
On Sep 28, 2012, at 5:54 PM, Jesse Gross wrote:
> On Fri, Sep 28, 2012 at 3:44 PM, Kyle Mestery (kmestery)
> wrote:
>> On Sep 28, 2012, at 5:40 PM, Jesse Gross wrote:
>>> On Fri, Sep 28, 2012 at 11:59 AM, Kyle Mestery (kmestery)
>>> wrote:
On Sep 28, 2012, at 1:12 PM, Jesse Gross wrote:
On Thu, Sep 27, 2012 at 5:44 PM, Simon Horman wrote:
> On Thu, Sep 27, 2012 at 04:45:22PM -0700, Jesse Gross wrote:
>> On Thu, Sep 27, 2012 at 12:05 PM, ravi kerur wrote:
>> > On Thu, Sep 27, 2012 at 11:16 AM, Jesse Gross wrote:
>> >> On Thu, Sep 27, 2012 at 9:26 AM, Ben Pfaff wrote:
>> >> > On
On Fri, Sep 28, 2012 at 6:25 AM, ravi kerur wrote:
> On Thu, Sep 27, 2012 at 5:44 PM, Simon Horman wrote:
>> On Thu, Sep 27, 2012 at 04:45:22PM -0700, Jesse Gross wrote:
>> > On Thu, Sep 27, 2012 at 12:05 PM, ravi kerur wrote:
>> > > On Thu, Sep 27, 2012 at 11:16 AM, Jesse Gross
>> > >> * If i
On Fri, Sep 28, 2012 at 3:17 PM, Giuseppe Lettieri
wrote:
> To me, it was that the existing code mostly worked and had already proved to
> be a real performance improvement. This coupled with the limited manpower we
> could pour on the project. I understand that turning a single-threaded
> prog
42 matches
Mail list logo
