Synthetic interfaces don't have database records so it doesn't make
sense to update them. In some situations this could cause a
segmentation fault.
Reported-by: Paul Ingram
Bug #7278.
---
vswitchd/bridge.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/vswitchd/bri
Thanks for the reviews.
Ethan
On Mon, Sep 12, 2011 at 19:10, Ben Pfaff wrote:
> It's fine.
>
> On Mon, Sep 12, 2011 at 06:47:36PM -0700, Ethan Jackson wrote:
>> I just thought it was easier to read. One line per output. If you
>> disagree I can squash it.
>>
>> Ethan
>>
>> On Mon, Sep 12, 2011
On Mon, Sep 12, 2011 at 05:43:25PM -0700, Ethan Jackson wrote:
> ofproto-dpif assumed that the datapath initialized the tun_id of a
> flow on egress, to its tun_id on ingress. For this reason, if
> OpenFlow actions set the tun_id to a flow's ingress tun_id,
> ofproto-dpif would fail to emit a set_
It's fine.
On Mon, Sep 12, 2011 at 06:47:36PM -0700, Ethan Jackson wrote:
> I just thought it was easier to read. One line per output. If you
> disagree I can squash it.
>
> Ethan
>
> On Mon, Sep 12, 2011 at 18:47, Ben Pfaff wrote:
> > On Mon, Sep 12, 2011 at 05:43:26PM -0700, Ethan Jackson w
I just thought it was easier to read. One line per output. If you
disagree I can squash it.
Ethan
On Mon, Sep 12, 2011 at 18:47, Ben Pfaff wrote:
> On Mon, Sep 12, 2011 at 05:43:26PM -0700, Ethan Jackson wrote:
>> This patch adds a unit test which would have caught the issue fixed
>> in Commit
On Mon, Sep 12, 2011 at 05:43:26PM -0700, Ethan Jackson wrote:
> This patch adds a unit test which would have caught the issue fixed
> in Commit 2446268e "ofproto-dpif: set_tunnel when required to."
Did you copy this from a test of resubmit? Otherwise why all the
resubmits?
I don't see any actua
This patch adds a unit test which would have caught the issue fixed
in Commit 2446268e "ofproto-dpif: set_tunnel when required to."
---
tests/ofproto-dpif.at | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
ind
ofproto-dpif assumed that the datapath initialized the tun_id of a
flow on egress, to its tun_id on ingress. For this reason, if
OpenFlow actions set the tun_id to a flow's ingress tun_id,
ofproto-dpif would fail to emit a set_tunnel action.
Reported-by: Igor Ganichev
Reported-by: Pankaj Thakkar
On Mon, Sep 12, 2011 at 09:30:10AM -0700, Ben Pfaff wrote:
> On Sat, Sep 10, 2011 at 03:09:31PM +0900, Simon Horman wrote:
> > By registering an error-handler for the init script used
> > in openvswitch-switch.postinst and detecting if module insertion fails,
> > it is possible to avoid failure to
Currently ovs is using device stats for Linux devices and count them
itself in other situations. This leads to overlap with hardware stats,
inconsistencies, etc. It's much better to just always count the packets
flowing through the switch and let userspace do any merging that it
wants.
Following pa
On Mon, Sep 12, 2011 at 4:53 PM, Jesse Gross wrote:
> On Mon, Sep 12, 2011 at 2:11 PM, Pravin Shelar wrote:
>> diff --git a/include/openvswitch/datapath-protocol.h
>> b/include/openvswitch/datapath-protocol.h
>> index c1c9ef0..49a122c 100644
>> --- a/include/openvswitch/datapath-protocol.h
>> ++
On Mon, Sep 12, 2011 at 2:11 PM, Pravin Shelar wrote:
> diff --git a/include/openvswitch/datapath-protocol.h
> b/include/openvswitch/datapath-protocol.h
> index c1c9ef0..49a122c 100644
> --- a/include/openvswitch/datapath-protocol.h
> +++ b/include/openvswitch/datapath-protocol.h
> @@ -237,8 +235
On Fri, Sep 09, 2011 at 05:46:20PM -0700, Ethan Jackson wrote:
> > +/* Optimized flow revalidation.
> > + *
> > + * It's a difficult problem, in general, to tell which facets need to have
> > + * their actions recalculated whenever the OpenFlow flow table changes. ?We
> > + * don't try to solve tha
On Fri, Sep 09, 2011 at 03:48:26PM -0700, Ethan Jackson wrote:
> > +/* Number of implemented OpenFlow tables. ?Must be between 1 and 255. */
> > +enum { N_TABLES = 255 };
>
> Does it make sense to use BUILD_ASSERT to enforce the allowed range?
Might as well. Added.
__
Good idea. I added one to flow_wildcards_is_exact(), too.
On Fri, Sep 09, 2011 at 03:46:15PM -0700, Ethan Jackson wrote:
> I would consider having this assert fail on FLOW_WC_SEQ.
>
> Seems fine otherwise,
> Ethan
>
> On Fri, Aug 19, 2011 at 15:28, Ben Pfaff wrote:
> > This will be used in an
On Tue, Aug 30, 2011 at 6:59 PM, Pravin Shelar wrote:
> diff --git a/datapath/actions.c b/datapath/actions.c
> index 8aec438..3178bdd 100644
> --- a/datapath/actions.c
> +++ b/datapath/actions.c
> +static int sample(struct datapath *dp, struct sk_buff *skb,
> + const struct nlattr
There is no need to have vport attribute MTU (OVS_VPORT_ATTR_MTU) as
linux net-dev-ioctl can be used to get/set MTU for linux device. Following
patch removes OVS_VPORT_ATTR_MTU from datapath protocol.
This patch also adds netdev_set_mtu interface. So that MTU adjustments
can be done from OVS us
On Mon, Sep 12, 2011 at 01:19:30PM -0700, Ethan Jackson wrote:
> >> I didn't realize that 2**0 was a standard bit numbering scheme. ?If
> >> you prefer it I'm fine with leaving it, either way is good.
> >
> > ** is just the way that "power" is written in some programming
> > languages (e.g. Fortran
>> I didn't realize that 2**0 was a standard bit numbering scheme. If
>> you prefer it I'm fine with leaving it, either way is good.
>
> ** is just the way that "power" is written in some programming
> languages (e.g. Fortran); 2 to the 0th power is 1.
>
> ^ is also a popular way to write "power",
On Mon, Sep 12, 2011 at 12:50:07PM -0700, Ethan Jackson wrote:
> > I was trying to refer to the bit with value 2**0. ?(There is some
> > ambiguity in bit numbering: some people consider bits to be numbered
> > left-to-right, so that this would be bit 7. ?See
> > http://en.wikipedia.org/wiki/Bit_num
On Mon, Sep 12, 2011 at 11:21:25AM -0700, Pravin Shelar wrote:
> On Mon, Sep 12, 2011 at 10:50 AM, Ben Pfaff wrote:
> > The 'vlan_tci' member of struct flow has value 0, not OFP_VLAN_NONE, when
> > there is no 802.1Q header.
> >
> > Fixes a problem introduced in commit d9065a90b6b "datapath: VLAN
On Mon, Sep 12, 2011 at 10:50 AM, Ben Pfaff wrote:
> The 'vlan_tci' member of struct flow has value 0, not OFP_VLAN_NONE, when
> there is no 802.1Q header.
>
> Fixes a problem introduced in commit d9065a90b6b "datapath: VLAN actions
> should use push/pop semantics."
>
> Found by sparse.
>
> CC: Pr
The 'vlan_tci' member of struct flow has value 0, not OFP_VLAN_NONE, when
there is no 802.1Q header.
Fixes a problem introduced in commit d9065a90b6b "datapath: VLAN actions
should use push/pop semantics."
Found by sparse.
CC: Pravin Shelar
---
ofproto/ofproto-dpif.c |2 +-
1 files changed
Thank you!
Patches #1 and #2 are now on "master" (patch #1 has been there since
last week).
All three patches are now on branch-1.2.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Sun, Sep 11, 2011 at 04:49:34PM +0900, Simon Horman wrote:
> > logic to the postinst script. As suggested by Ben Phaff
>
> Ben, I apologise for misspelling your name.
No big deal, I actually hadn't noticed until you pointed it out.
___
dev mailing
On Sat, Sep 10, 2011 at 03:09:31PM +0900, Simon Horman wrote:
> By registering an error-handler for the init script used
> in openvswitch-switch.postinst and detecting if module insertion fails,
> it is possible to avoid failure to install in the case where the
> openvswitch_mod module is not avail
On Fri, Sep 9, 2011 at 11:23 PM, Simon Horman wrote:
> On Thu, Sep 08, 2011 at 02:39:45AM -0700, Jesse Gross wrote:
>> From: Valient Gough
>>
>> Add tunnel key support to CAPWAP vport. Uses the optional WSI field in a
>> CAPWAP header to store a 64bit key. It can also be used without keys, in
On Mon, Sep 12, 2011 at 12:43:00PM +0500, Bibrak Qamar wrote:
> While PORTING OVS 1.2.* to a harware, ofproto-provider is necessary for
> expoiting HW capabilities. There is a ofproto-provider included in the
> package called ofproto-dpif.c.
>
> Now that ofproto.c maintains the OpenFlow table (wil
Hello all,
While PORTING OVS 1.2.* to a harware, ofproto-provider is necessary for
expoiting HW capabilities. There is a ofproto-provider included in the
package called ofproto-dpif.c.
Now that ofproto.c maintains the OpenFlow table (wildcarded, classifier) and
netdev maintains the rule table (ex
29 matches
Mail list logo
