Hi,
Does the latest GIT Master has any dependency of other kernel modules like the
listed below?
# modinfo openvswitch.ko
filename: openvswitch.ko
version:1.12.90
license:GPL
description:Open vSwitch switching datapath
srcversion: B883906E388F7AE70C7125C
depends:
This looks like the path of least resistance. We can always change it in
the future if it's an issue. Cheers for handling this.
On Tue, Aug 27, 2013 at 9:18 AM, Jesse Gross wrote:
> I see what you mean about there being several implementations...
>
> The main thing that I was trying to get at w
Acked-by: Ethan Jackson
On Mon, Aug 26, 2013 at 5:10 PM, Ben Pfaff wrote:
> In an Open vSwitch flow table that has a configured maximum number of
> flows, flows that have an idle or hard timeout, or both, are expirable,
> and flows with neither are permanent. The fin_timeout action can change
> +/* Replaces 'dst' by 'src', destroying 'src'. The caller must eventually
> free
> + * 'dst' with miniflow_destroy(). */
> +void
> +miniflow_move(struct miniflow *dst, struct miniflow *src)
> +{
> +int n = miniflow_n_values(src);
> +if (n <= MINI_N_INLINE) {
> +dst->values = dst
Acked-by: Ethan Jackson
On Mon, Aug 26, 2013 at 5:10 PM, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff
> ---
> include/openflow/openflow-1.0.h |2 +-
> lib/ofp-util.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/openflow/openflow-1.
This function will acquire its first user in an upcoming commit.
Signed-off-by: Ben Pfaff
---
lib/classifier.c | 12 +++-
lib/classifier.h |3 ++-
lib/flow.c | 23 +++
lib/flow.h |2 ++
lib/match.c |9 +
lib/match.h |3
add_flow() in ofproto.c has a race: it adds a new flow to the flow table
before calling ->rule_construct(). That means that (in ofproto-dpif) the
new flow is visible to the forwarder threads before gets properly
initialized.
One solution would be to lock the flow table across the entire operation
Signed-off-by: Ben Pfaff
---
include/openflow/openflow-1.0.h |2 +-
lib/ofp-util.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/openflow/openflow-1.0.h b/include/openflow/openflow-1.0.h
index f2b90db..ef0a3ce 100644
--- a/include/openflow/
The OFPFF_* flags used in flow_mods are just confusing enough that it
seems worthwhile to try to abstract them out. In particular:
* OFPFF_EMERG was introduced in OF1.0, deleted in OF1.1, and then
its bit was reused for a different purpose in OF1.2.
* OFPFF_RESET_COUNTS was introdu
In an Open vSwitch flow table that has a configured maximum number of
flows, flows that have an idle or hard timeout, or both, are expirable,
and flows with neither are permanent. The fin_timeout action can change
a flow that has no idle or hard timeout into one that has either one or
both, which
There is a race in add_flow() in ofproto.c, in that the flow becomes
visible in the flow table (to the forwarding threads) before it is
initialaized. This tends to cause crashes under load when the flow table
is changing. This series of commits fixes the problem.
Ben Pfaff (6):
Fix typos in a
add_flow() in ofproto.c has a race: it adds a new flow to the flow table
before calling ->rule_construct(). That means that (in ofproto-dpif) the
new flow is visible to the forwarder threads before gets properly
initialized.
One solution would be to lock the flow table across the entire operation
I found answer from here:
http://stackoverflow.com/questions/337449/how-does-one-declare-an-array-of-constant-function-pointers-in-c
so if i understand it correctly:
extern int (*build_assert(void))[1];
declare an extern function pointer 'build_assert', pointing to a function
that takes no input
Also, in viewing the util.h code, I saw,
extern int (*build_assert(void))[1];
want to ask: what is the "(*build_assert(void))" ?
Thanks,
On Mon, Aug 26, 2013 at 1:24 PM, Alex Wang wrote:
> Thanks Ben for the review,
>
>
> > +static long long int coverage_run_time = LLONG_MIN;
>> > +
>> > +/*
I see what you mean about there being several implementations...
The main thing that I was trying to get at was whether we should add
some kind of dependency (through select/depends) or make the OVS SCTP
functionality dependent on a config option. We have the latter for
VXLAN and GRE support since
Remove push_vlan from an OF1.0 test, as it requires OF1.1+ support, but was
silently discarded. A later patch will make this test to fail due to
validation of usable OpenFlow protocol versions while parsing actions.
It should be noted that existing controllers may depend on the silently
discarded
Thanks Ben for the review,
> +static long long int coverage_run_time = LLONG_MIN;
> > +
> > +/* Defines the moving average array index variables. */
> > +static unsigned int min_idx = 0;
> > +static unsigned int hr_idx = 0;
>
> It looks to me that min_idx and hr_idx are used only in
> coverage_ru
On Mon, Aug 26, 2013 at 01:10:34PM -0700, Jarno Rajahalme wrote:
>
> On Aug 26, 2013, at 10:45 AM, Ben Pfaff wrote:
>
> > On Tue, Aug 20, 2013 at 06:41:44PM -0700, Jarno Rajahalme wrote:
> >> Remove push_vlan from an OF1.0 test, as it requires OF1.1+ support, but was
> >> silently discarded.
> >
On Aug 26, 2013, at 10:45 AM, Ben Pfaff wrote:
> On Tue, Aug 20, 2013 at 06:41:44PM -0700, Jarno Rajahalme wrote:
>> Remove push_vlan from an OF1.0 test, as it requires OF1.1+ support, but was
>> silently discarded.
>>
>> Signed-off-by: Jarno Rajahalme
>
> I agree that we should not expect OF
Thanks, I'll apply this soon.
On Mon, Aug 26, 2013 at 12:58:41PM -0700, Jarno Rajahalme wrote:
> This looks right, compiles and tests ok.
>
> Acked-by: Jarno Rajahalme
>
>
> On Aug 20, 2013, at 11:10 AM, Ben Pfaff wrote:
>
> > With this implementation I get warnings with Clang on GNU/Linux w
This looks right, compiles and tests ok.
Acked-by: Jarno Rajahalme
On Aug 20, 2013, at 11:10 AM, Ben Pfaff wrote:
> With this implementation I get warnings with Clang on GNU/Linux when the
> previous patch is not applied. This ought to make it easier to avoid
> introducing new problems in th
On Mon, Aug 26, 2013 at 12:45:33PM -0700, Gurucharan Shetty wrote:
> On Mon, Aug 26, 2013 at 11:29 AM, Ben Pfaff wrote:
>
> > On Mon, Aug 26, 2013 at 10:48:30AM -0700, Gurucharan Shetty wrote:
> > > Reported-by: Jian Qiu
> > > Signed-off-by: Gurucharan Shetty
> >
> > Scripts of this kind don't
On Mon, Aug 26, 2013 at 12:17:19PM -0700, Gurucharan Shetty wrote:
> Reported-by: Jian Qiu
> Signed-off-by: Gurucharan Shetty
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Reported-by: Jian Qiu
Signed-off-by: Gurucharan Shetty
---
utilities/ovs-save | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/utilities/ovs-save b/utilities/ovs-save
index b46f98d..73895f3 100755
--- a/utilities/ovs-save
+++ b/utilities/ovs-save
On Mon, Aug 26, 2013 at 11:29 AM, Ben Pfaff wrote:
> On Mon, Aug 26, 2013 at 10:48:30AM -0700, Gurucharan Shetty wrote:
> > Reported-by: Jian Qiu
> > Signed-off-by: Gurucharan Shetty
>
> Scripts of this kind don't traditionally rely on "which". I am not
> sure why--maybe it is only for histori
On Mon, Aug 26, 2013 at 11:05 AM, Pravin B Shelar wrote:
> Upstream vxlan implementation was changed according to few
> comments. Following patch brings back those changes to out
> of tree ovs module.
>
> Signed-off-by: Pravin B Shelar
I think we could also kill off VXLAN_N_VID and VXLAN_VID_MA
On Mon, Aug 26, 2013 at 10:48:30AM -0700, Gurucharan Shetty wrote:
> Reported-by: Jian Qiu
> Signed-off-by: Gurucharan Shetty
Scripts of this kind don't traditionally rely on "which". I am not
sure why--maybe it is only for historical reasons. I do see that
POSIX does not specify "which"; mayb
On Wed, Aug 21, 2013 at 11:45:08AM -0700, Alex Wang wrote:
> This commit changes the "ovs-appctl coverage/show" command to show the
> per-second, per-minute and per-hour rates of function invocation. More
> importantly, this makes using coverage counter an easy way to monitor
> the execution of sp
On Mon, Aug 26, 2013 at 10:40 AM, Ben Pfaff wrote:
> On Mon, Aug 26, 2013 at 06:41:32PM +0800, Jian Qiu wrote:
> > If user installed openvswitch in /usr/local/bin, utilities/ovs-save
> script
> > would fail as missing_program routine did no check /usr/local/bin.
>
> I'm not sure why we're setting
Reported-by: Jian Qiu
Signed-off-by: Gurucharan Shetty
---
utilities/ovs-save | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/utilities/ovs-save b/utilities/ovs-save
index b46f98d..dab6a1b 100755
--- a/utilities/ovs-save
+++ b/utilities/ovs-save
Upstream vxlan implementation was changed according to few
comments. Following patch brings back those changes to out
of tree ovs module.
Signed-off-by: Pravin B Shelar
---
v1-v2:
- remove vxlan-dev hash table and vs->refcnt.
- update copyright.
---
datapath/linux/compat/include/net/vxlan.h |
On Tue, Aug 20, 2013 at 06:41:45PM -0700, Jarno Rajahalme wrote:
> Keep track of usable protocols while parsing actions and matches,
> rather than checking for them afterwards. This fixes silently discarded
> meter and goto table instructions when not explicitly specifying the
> protocol to use.
>
If there is a lot of churn in creation and deletion of
interfaces, we may end up recycling the ofport value of a
recently deleted interface for a newly created interface.
This may result in an old stale openflow rule applying
on the newly created interface.
With this commit, when a new port is add
On Tue, Aug 20, 2013 at 06:41:44PM -0700, Jarno Rajahalme wrote:
> Remove push_vlan from an OF1.0 test, as it requires OF1.1+ support, but was
> silently discarded.
>
> Signed-off-by: Jarno Rajahalme
I agree that we should not expect OF1.1+ features to work in OF1.0,
but I think that this test r
On Mon, Aug 26, 2013 at 06:41:32PM +0800, Jian Qiu wrote:
> If user installed openvswitch in /usr/local/bin, utilities/ovs-save script
> would fail as missing_program routine did no check /usr/local/bin.
I'm not sure why we're setting $PATH there at all. It might be better
to simply remove it.
__
Centro de Reparos NFS - Reparamos todas as marcas e modelos de equipamentos com
tecnologias Wireless, VoIP, Network, Telecom, Cameras e Dispositivos de
Seguranca. Atendemos a fabricantes, revendas, distribuidores, usuarios
corporativos e usuarios finais. Equipamentos VoIP, ATAs, Gateways VoIP,
On Thu, Aug 22, 2013 at 3:04 AM, James Page wrote:
> Disable GRE compat layer for >= 3.11 as datapath is in sync with
> the kernel in 3.11 so use of compat no longer required.
>
This patch does not work since it is still using compat
iptunnel_xmit(). We can not turn off iptunnel_xmit() compat code
On Fri, Aug 23, 2013 at 4:30 PM, Jesse Gross wrote:
> On Tue, Aug 20, 2013 at 2:31 PM, Pravin B Shelar wrote:
>> Upstream vxlan implementation was changed according to few
>> comments. Following patch brings back those changes to out
>> of tree ovs module.
>>
>> Signed-off-by: Pravin B Shelar
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/08/13 18:10, Pravin Shelar wrote:
> On Thu, Aug 22, 2013 at 3:04 AM, James Page
> wrote:
>> Disable GRE compat layer for >= 3.11 as datapath is in sync with
>> the kernel in 3.11 so use of compat no longer required.
>>
> This patch does not
On Mon, Aug 26, 2013 at 2:03 AM, Viresh Kumar wrote:
> On 24 August 2013 06:30, Jesse Gross wrote:
>> Putting a big lock around the majority of the packet processing
>> doesn't seem like a particularly good idea for performance and you
>> would need to make sure that you get all the entry points.
On Sun, Aug 25, 2013 at 11:36 PM, Viresh Kumar wrote:
> This was causing it to fail against latest RT kernels, with following errors:
>
> In file included from
> /home/arm/work/kernel/linaro/lng/openvswitch/datapath/linux/compat/include/linux/if_vlan.h:6:0,
> from
If user installed openvswitch in /usr/local/bin, utilities/ovs-save script
would fail as missing_program routine did no check /usr/local/bin.
diff --git a/utilities/ovs-save b/utilities/ovs-save
index b46f98d..faaa076 100755
--- a/utilities/ovs-save
+++ b/utilities/ovs-save
@@ -33,7 +33,7 @@ This
On 24 August 2013 06:30, Jesse Gross wrote:
> Putting a big lock around the majority of the packet processing
> doesn't seem like a particularly good idea for performance and you
> would need to make sure that you get all the entry points. You would
> probably be better off serializing the parts t
43 matches
Mail list logo
