Re: [ovs-dev] kernel module testing

[Pritesh Kothari (pritkoth)]

> On Jul 13, 2015, at 9:40 PM, Ben Pfaff  wrote:
> 
> On Tue, Jul 14, 2015 at 12:34:14AM +, Pritesh Kothari (pritkoth) wrote:
>> How about automating this using travis and gerrit, so no commit gets in
>> unless it passes sanity tests? This also simplifies review process as well.
> 
> Travis doesn't test the kernel module, and as far as I know it can’t.

weird, i saw one patch few days ago doing it [1], anyways I may be mistaken.

> 
> I am the wrong person to evangelize Gerrit to:
>http://benpfaff.org/writings/gerrit.html

This seems to be all about web interface, any chance you happen to use the
cli for gerrit mainly git review [2] -d [3] or -m [3] or gerritmander [4]? both 
of
them are really good utilities and you never have to really leave your
command line tools to use them. 

To answer a few points from your webpage from Review text section:

Q) Gerrit provides the patch submitter no way to say what has changed in the 
second or later version of a patch, even though this is critical information. 
(Gerrit does provide an interface to view differences relative to a prior 
versions of a patch set, but it isn't useful because it folds in unrelated 
changes that have occurred in the repository in the meantime.)
A) it does: If you want to compare patchset 4 with patchset 10 of change 781 
from gerrit: git review -m 781,4-10

Q) Gerrit does not provide a way to save a draft of a review.
A) it does: If you want to download patchset 4 for change 781 from gerrit to 
review it: git review -d 781,4

Q) Gerrit adds extra data with no obvious value to commit messages (Change-Id: 
…).
A) The extra data provides a way to link dependencies across projects ;) check 
this [5] by clicking the Depends-on link and you will see that 
python-neutronclient patch depends upon neutron project patch.

[1]: 
https://github.com/suffuse/go-suffuse/pull/14/files#diff-d92eb0153aa9cbf834f7ab1aeab150a7R16
[2]: https://launchpad.net/git-review
[3]: 
https://github.com/openstack-infra/git-review/blob/master/doc/source/usage.rst
[4]: https://github.com/berrange/gerrymander
[5]: https://review.openstack.org/#/c/162040/
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 0/5 V6] Add 802.1ad (qinq) support

[ravulakollu.kumar]

Hi Thomas,

Thanks for your reply. Seems I was using old patch 
http://patchwork.openvswitch.org/patch/3686/ (version 3). It would be really
helpful if you could let me know the link where I can download version 11 patch 
code.

Also I have few queries like, does version 11 patch includes configuration 
plane handling ?  or it is simply Forwarding behavior.

If configuration handling is supported, whether it is via ovs-ofctl (openflow 
bridge mode) or ovs-vsctl (normal bridge mode) ? ,
please, let me know where I can get information about 802.1ad configuration.

Thanks in Advance,
Uday

-Original Message-
From: Thomas F Herbert [mailto:thomasfherb...@gmail.com]
Sent: Monday, July 13, 2015 11:15 PM
To: Ravulakollu Udaya Kumar (WT01 - Digital Marketing); dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH 0/5 V6] Add 802.1ad (qinq) support

On 7/13/15 8:05 AM, ravulakollu.ku...@wipro.com wrote:
> Hi All,
>
> I am trying to configure vlan stacking (802.1ad) to few ovs bridge
> ports, in Normal mode bridge operation. I am using ovs-master code Version 
> 2.3.9 for my experiments.
> I am seeing no support for stacked vlans both from the configuration 
> interface perspective and datapath as well.
>
> I am trying to come up with the design and implementation of configuration 
> interface support for 802.1ad  (ovs-vsctl) and also datapath support.
> Currently as I understand ovs-vsctl vlan configuration has the following 
> modes defined in ovsdb: access, native−tagged, native−untagged, and trunk.
>
> I have the following configuration in my mind for 1ad support.
>  1.Access port : 
> Adds C-VLAN ,does 802.1q tagging as usual, Ex: tag =10)
>  3.Trunk port without qinq support   : On ingress by default 
> receives all vlan tagged traffic(single) , sends the same out of egress. 
> (double tagged traffic currently misbehaving)
>  4.Trunk port with qinq support  : On ingress adds a 
> specific S-VLAN for a specific customer. On egress pops S-VLAN.
>
> As I understand access port doesn’t require qinq support , so
> supporting the same for trunk ports only
>
> It would be really helpful , if you could let me know your suggestions
> and comments towards my approach. Also let me know how the ovs community is 
> approaching towards 802.1ad, So that it will be in sync with ovs community 
> thoughts.
Version 11 of the 802.1ad patch was submitted about 1 week ago. I am currently 
working on version 12 which incorporates some comments from reviewers.
>
> Also I am seeing multiple patches for 1ad support in datapath, though
> few not working for me. Please, let me know if any working patch is available 
> that would greatly save my time in this experiment.
Please send information about what version of the patch you tried and with 
information about the failure case.
>
> Thanks in Advance,
> Uday
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any
> attachments. WARNING: Computer viruses can be transmitted via email.
> The recipient should check this email and any attachments for the
> presence of viruses. The company accepts no liability for any damage
> caused by any virus transmitted by this email. www.wipro.com
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC net-next 18/22] openvswitch: Make tunnel set action attach a metadata dst

[Thomas Graf]

On 07/13/15 at 03:55pm, Joe Stringer wrote:
> It doesn't look like flow_free() is using this new function to
> properly free the actions. Also, some of the error cases that hit this
> code have sf_acts=NULL.

Good catch. Will fix in next iteration.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] IS MSTP enabled on OVS 2.3.9

[ravali.burra]

Hi Team,

I am using ovs-master code Version 2.3.9 for my experiments.

Currently what I understood from ovs-vsctl  man page we are having commands for 
the configuring  RSTP.

Similar way I want  to configure MSTP in OVS  but I have not  seen any 
supported commands for configuration of MSTP from the interface perspective.



Can you please suggest me in bringing up with the design and implementation of 
configuration for bridge and interface support for MSTP (ovs-vsctl) and also 
datapath support.



Thanks in advance.
Thanks & Regards,
Ravali.
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] ovs-ofctl mod-table commands supporting OF1.4 Eviction and Vacancy-Events

[Saloni Jain]

Hi Ben,

In addition to my previous response, please suggest if "vswitchd" should query 
and get the current stored table-configurartion using query_tables_desc() and 
then modify table-config properties according to user's request.

Thanks and Regards,
Saloni Jain
Tata Consultancy Services
Mailto: saloni.j...@tcs.com
Website: http://www.tcs.com

Experience certainty.   IT Services
Business Solutions
Consulting



-"dev"  wrote: -
To: Ben Pfaff 
From: Saloni Jain 
Sent by: "dev" 
Date: 07/14/2015 11:40AM
Cc: dev@openvswitch.org, Deepankar Gupta , Partha 
Datta 
Subject: Re: [ovs-dev] ovs-ofctl mod-table commands supporting OF1.4
Eviction and Vacancy-Events

Hi Ben,

Thanks for the reply.
Please help me understand below points:
As per openflow specification 1.4, Page 72 "The flag OFPTC_VACANCY_EVENTS 
control vacancy events in that table (see 7.4.5). If this flag is set, the 
switch must generate vacancy events for that table. If this flag is unset, the 
switch must not generate those events. Parameters for vacancy events may be 
specified using the OFPTMPT_VACANCY property."

This means that OFPTC_VACANCY_EVENTS is property for the table and not for 
per-OpenFlow connection basis.

Regarding the events, then only those controller will get vacancy events which 
have OFPT_TABLE_STATUS messages set on using "set-async configuration" 
OFPT_SET_ASYNC.
Page 121 of openflow 1.4 says that "The OFPT_SET_ASYNC message sets whether a 
controller should receive a given asynchronous message that is generated by the 
switch. Other OpenFlow features control whether a given message is generated; 
for example, the OFPFF_SEND_FLOW_REM flag in each flow entry controls whether 
the switch generates a OFPT_FLOW_REMOVED message when a flow entry is removed. 
The asynchronous configuration acts as an additional per-controller filter; for 
example it defines if a specific controller receives those OFPT_FLOW_REMOVED 
messages."

So as per my understanding OFPTC_VACANCY_EVENTS set as config property will 
generate vacancy_events using OFPT_TABLE_STATUS message type and reason 
OFPTR_VACANCY_DOWN/OFPTR_VACANCY_UP for that table, but only those controller 
will receive those events which have OFPT_TABLE_STATUS messages turned on via 
OFPT_SET_ASYNC message.

Thanks and Regards,
Saloni Jain
Tata Consultancy Services
Mailto: saloni.j...@tcs.com
Website: http://www.tcs.com

Experience certainty.   IT Services
Business Solutions
Consulting



-Ben Pfaff  wrote: -
To: Saloni Jain 
From: Ben Pfaff 
Date: 07/14/2015 10:45AM
Cc: dev@openvswitch.org, Partha Datta , Deepankar Gupta 

Subject: Re: ovs-ofctl mod-table commands supporting OF1.4 Eviction and 
Vacancy-Events

On Mon, Jul 13, 2015 at 08:23:45AM -0700, Ben Pfaff wrote:
> On Mon, Jul 13, 2015 at 04:19:46PM +0530, Saloni Jain wrote:
> > 2. ovs-ofctl -O Openflow14 mod-table   vacancy-   
> > -- To be implemented
> > OFPTC14_VACANCY_EVENTS is the only set table-mod config property and 
> > eviction if configured previously will get unset.
> 
> I don't think it's good for mod-table to affect properties that the user
> didn't request.  I suggest that "ovs-ofctl table-mod" should, when
> necessary, first use an OFPMP_TABLE_DESC request to obtain the current
> configuration, then modify it according to the user's request.

Actually, let me take that back.  I think that OFPTC14_VACANCY_EVENTS
should be implemented on a per-OpenFlow connection basis.  That is, if a
controller turns on OFPTC14_VACANCY_EVENTS, then this should affect its
connection only; no other connections should receive the vacancy events.
That makes more sense to me than to have an ovs-ofctl call affect all
subsequent OpenFlow connections (in either direction), because a given
controller is the only entity that knows whether it wants to receive
vacancy events.
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [ovn-controller-vtep V3 5/7] ovn-controller-vtep: Add gateway module.

[Russell Bryant]

Awesome work.  I plan to do a more in depth review but I had a quick
comment about something I thought of last night.

On 07/13/2015 11:22 PM, Alex Wang wrote:
> This commit adds the gateway module to ovn-controller-vtep.  The
> module will register the physical switches to ovnsb as chassis and
> constantly update the "logical_switches" column in Chassis table.
> 
> Limitation:
> 
> - Do not support reading multiple tunnel ips of physical switch.
> 
> Signed-off-by: Alex Wang 

> +/* If not already in 'lswitches', adds the logical switch
> + * to logical port map.  The logical port is defined as
> + * {pswitch->name}_{ls->name}. */
> +if (!smap_get(&lswitches, ls->name)) {
> +char *lport = xasprintf("%s_%s", pswitch->name, 
> ls->name);
> +
> +smap_add(&lswitches, ls->name, lport);

I'm going to need a way to make sure that an OpenStack Neutron end user
is not able to create ports with a name that could interfere with
special port names.  I'm going to need special port names for the
Neutron provider networks thing I'm working on, too.

A simple solution would be to adopt a convention where we prefix all
special port names with "ovn_".  The Neutron driver could just reject
any port names specified by users with that prefix and only use that for
ports created automatically for a special purpose.

I suppose a cleaner solution would be to avoid having any special port
names, but I'm happy to just consider that something we may do later.

What do you think?

-- 
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [ovn-controller-vtep V3 7/7] ovn-controller-vtep: Add pipeline module.

[Liran Schour]

"dev"  wrote on 14/07/2015 06:22:43 AM:

> This commit adds the pipeline module to ovn-controller-vtep.  The
> module will scan through the Binding table, and create the
> Ucast_Macs_Remote in vtep database for each logical port's MACs in
> the same logical datapath (same as logical switch for vtep).  Also
> the module will create the physical locators to each HV chassis in
> the same logical datapath.
> 
> TODO:
> 
> - vtep gateway will create entries in the "Ucast_Macs_Local" for
>   each MAC learned.  ovn-controller-vtep should take advantage of
>   this and notify the ovn-sb database in some way so that all HVs
>   (in the same logical datapath) are aware of these MACs and will
>   send all related packets to the vtep gateway.  We should achieve
>   this in the near future.
> 
> Signed-off-by: Alex Wang 
> 

For clarification. Do you expect someone to add logical port with unknown 
MAC to the NB DB?
If so why not to do the learning through the NB DB and add the learned 
MACs there. It will be projected to the SB DB by northd.

Thanks,
- Liran
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] another provider network idea (was: [RFC] ovn: physical network integraiton (WIP))

[Ben Pfaff]

I think that the various issues with trying to treat a provider network
as a logical network are going to difficult to resolve.  I think that
they reflect a conceptual difference between OVN logical networks and
provider networks.  OVN knows the hosts on a logical network and where
they reside, but it doesn't know that for a provider network, and can't
do anything related to specific hosts except in the pathological case
where they reside on the same hypervisor.  Broadcast may be a problem,
but so is a simple output to any port: it's impossible unless the source
and destination ports are on the same hypervisor.  So my thought is that
modeling a provider network as an OVN logical network is unlikely to be
fruitful (unless we change the OVN logical network model significantly).

Here's an a strawman alternative.  Instead of representing a provider
network as a single logical network, represent it as a collection of
logical networks, one for each connected port.  Each of these logical
networks has only two ports, the VM's port plus a physical port on the
hypervisor where the VM resides (or more likely a patch port to the
bridge that contains the physical port; the other end of the patch port
can be an access port if it's a VLAN provider network).  It seems to me
that this models the situation more naturally.

Thoughts?

Thanks,

Ben.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/2] dpif-netdev: Don't use designated initializers.

[Gurucharan Shetty]

On Mon, Jul 13, 2015 at 2:12 PM, Jesse Gross  wrote:
> On Fri, Jul 10, 2015 at 9:26 PM, Gurucharan Shetty  wrote:
>> MSVC 2013 does not like designated initializers when
>> structs are initialized inside structs.
>>
>> Signed-off-by: Gurucharan Shetty 
>
> This looks fine to me, although there are several other instances of
> this pattern in other places. Are the ones in ofproto/ofproto-dpif.c,
> for example, which also initialize .support different enough that they
> slip into some weird corner case that is OK?
I started looking more at the reason on why the change in dpif-netdev
causes failures and why the use of designated initializers in
ofproto-dpif does not. So one thing that I have in public domain is
this: 
https://connect.microsoft.com/VisualStudio/feedback/details/805981/msvc-2013-c99-designated-initializers-cannot-initialize-unions-within-structs

Based on the above, my first feeling is that because struct flow has
unions inside it, that may be the reason. I also noticed that
Microsoft had marked the issue as resolved. So I downloaded their
latest upgrade pack "visual studio 2103 update 4" and that does not
have any problems. Looks like Appveyor uses the same upgrade pack and
so we do not see the same problem at appveyor anymore.

So I will just drop this patch and use the latest MSVC 2013 instead.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] CodingStyle: Remove designated initialzers as acceptable.

[Gurucharan Shetty]

On Sat, Jul 11, 2015 at 9:56 AM, Ben Pfaff  wrote:
> On Fri, Jul 10, 2015 at 09:26:07PM -0700, Gurucharan Shetty wrote:
>> MSVC 2013 does not like designated initializers when
>> structs are initialized inside structs.
>>
>> Signed-off-by: Gurucharan Shetty 
>
> Ugh.
>
> Acked-by: Ben Pfaff 
>
> (Patch 1 looked OK too but I'm not really an expert on that code anymore
> so I'd prefer to get a review from someone else.)

I decided to drop this series as the issue of designated initializers
seems to be fixed in MSVC 2013 "update 4". The public information that
exists is here:
https://connect.microsoft.com/VisualStudio/feedback/details/805981/msvc-2013-c99-designated-initializers-cannot-initialize-unions-within-structs
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/2] dpif-netdev: Don't use designated initializers.

[Jesse Gross]

On Tue, Jul 14, 2015 at 8:18 AM, Gurucharan Shetty  wrote:
> On Mon, Jul 13, 2015 at 2:12 PM, Jesse Gross  wrote:
>> On Fri, Jul 10, 2015 at 9:26 PM, Gurucharan Shetty  
>> wrote:
>>> MSVC 2013 does not like designated initializers when
>>> structs are initialized inside structs.
>>>
>>> Signed-off-by: Gurucharan Shetty 
>>
>> This looks fine to me, although there are several other instances of
>> this pattern in other places. Are the ones in ofproto/ofproto-dpif.c,
>> for example, which also initialize .support different enough that they
>> slip into some weird corner case that is OK?
> I started looking more at the reason on why the change in dpif-netdev
> causes failures and why the use of designated initializers in
> ofproto-dpif does not. So one thing that I have in public domain is
> this: 
> https://connect.microsoft.com/VisualStudio/feedback/details/805981/msvc-2013-c99-designated-initializers-cannot-initialize-unions-within-structs
>
> Based on the above, my first feeling is that because struct flow has
> unions inside it, that may be the reason. I also noticed that
> Microsoft had marked the issue as resolved. So I downloaded their
> latest upgrade pack "visual studio 2103 update 4" and that does not
> have any problems. Looks like Appveyor uses the same upgrade pack and
> so we do not see the same problem at appveyor anymore.
>
> So I will just drop this patch and use the latest MSVC 2013 instead.

Awesome!
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] netdev-linux: do not warn when getting stats for netdev with no vport

[Thadeu Lima de Souza Cascardo]

On Mon, Jul 13, 2015 at 09:02:17AM -0700, Ben Pfaff wrote:
> On Tue, Jul 07, 2015 at 03:38:51PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > When there is no vport for a given netdev, dpif_netlink_vport_get might 
> > return
> > ENODEV. Do not warn a failure to get port stats when that's the case.
> > 
> > Signed-off-by: Thadeu Lima de Souza Cascardo 
> 
> Can you give some more context about when this gets reported?  I haven't
> seen anyone complaining about spurious warnings.

Just use a bridge with type netdev, it will show up right after starting
vswitchd, for the internal port and linux ports. Since they are not added to the
netlink dpif, trying to get vports stats will return ENODEV.

Feel free to paraphrase that on the commit message, or ask me to send a v2.

Thanks a lot.
Cascardo.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [ovn-controller-vtep V3 5/7] ovn-controller-vtep: Add gateway module.

[Alex Wang]

On Tue, Jul 14, 2015 at 6:25 AM, Russell Bryant  wrote:

> Awesome work.  I plan to do a more in depth review but I had a quick
> comment about something I thought of last night.
>
> On 07/13/2015 11:22 PM, Alex Wang wrote:
> > This commit adds the gateway module to ovn-controller-vtep.  The
> > module will register the physical switches to ovnsb as chassis and
> > constantly update the "logical_switches" column in Chassis table.
> >
> > Limitation:
> >
> > - Do not support reading multiple tunnel ips of physical switch.
> >
> > Signed-off-by: Alex Wang 
>
> > +/* If not already in 'lswitches', adds the logical
> switch
> > + * to logical port map.  The logical port is defined as
> > + * {pswitch->name}_{ls->name}. */
> > +if (!smap_get(&lswitches, ls->name)) {
> > +char *lport = xasprintf("%s_%s", pswitch->name,
> ls->name);
> > +
> > +smap_add(&lswitches, ls->name, lport);
>
> I'm going to need a way to make sure that an OpenStack Neutron end user
> is not able to create ports with a name that could interfere with
> special port names.  I'm going to need special port names for the
> Neutron provider networks thing I'm working on, too.
>
> A simple solution would be to adopt a convention where we prefix all
> special port names with "ovn_".  The Neutron driver could just reject
> any port names specified by users with that prefix and only use that for
> ports created automatically for a special purpose.
>


Could you explain more on what falls into the 'special port' category?
only gateway logical ports or also the hv logical ports?  I think the
ovn-controller just read the attached port from integration bridge without
prefixing.  So, could it also be a collision there?



>
> I suppose a cleaner solution would be to avoid having any special port
> names, but I'm happy to just consider that something we may do later.
>
>
I'm fine with that, should be simple to change.  I'd like to wait to see
what
Ben think about this also~

Thanks,
Alex Wang,


> What do you think?
>
> --
> Russell Bryant
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] another provider network idea

[Russell Bryant]

On 07/14/2015 10:59 AM, Ben Pfaff wrote:
> I think that the various issues with trying to treat a provider network
> as a logical network are going to difficult to resolve.  I think that
> they reflect a conceptual difference between OVN logical networks and
> provider networks.  OVN knows the hosts on a logical network and where
> they reside, but it doesn't know that for a provider network, and can't
> do anything related to specific hosts except in the pathological case
> where they reside on the same hypervisor.  Broadcast may be a problem,
> but so is a simple output to any port: it's impossible unless the source
> and destination ports are on the same hypervisor.  So my thought is that
> modeling a provider network as an OVN logical network is unlikely to be
> fruitful (unless we change the OVN logical network model significantly).

Yes, that seems to be what I'm hitting as I keep working on this.  The
more I've worked on trying to make this work using a single OVN logical
network, the more I feel like it just isn't making sense.

> Here's an a strawman alternative.  Instead of representing a provider
> network as a single logical network, represent it as a collection of
> logical networks, one for each connected port.  Each of these logical
> networks has only two ports, the VM's port plus a physical port on the
> hypervisor where the VM resides (or more likely a patch port to the
> bridge that contains the physical port; the other end of the patch port
> can be an access port if it's a VLAN provider network).  It seems to me
> that this models the situation more naturally.
> 
> Thoughts?

That's a really interesting idea.  Conceptually it seems to map much
nicer than the previous approach.  A logical port with MACs configured
as "unknown" matches the processing needed.  I'm going to go down this
road and see what I can come up with.

Some misc implementation thoughts ...

When Neutron creates these ports, it needs to indicate that one of the
ports is special and maps to local connectivity to the provider network.
 The ovn-controller-vtep work has similar needs and is doing so with a
special port name that follows a particular pattern.

In the case of ovn-controller-vtep, it's using the pattern:

   _

For provider networks, I need:

  - physical network name, which maps to a local ovs bridge
determined by configuration local to each ovn-controller

  - Optionally a VLAN ID

I was previously thinking that special names was fine, but maybe we
should go ahead and add attributes to the logical port in OVN_Northbound
to handle this.

For reference, the current schema is:

> "Logical_Port": {
> "columns": {
> "name": {"type": "string"},
> "parent_name": {"type": {"key": "string", "min": 0, "max": 
> 1}},
> "tag": {
>  "type": {"key": {"type": "integer",
>   "minInteger": 0,
>   "maxInteger": 4095},
>   "min": 0, "max": 1}},
> "macs": {"type": {"key": "string",
>   "min": 0,
>   "max": "unlimited"}},
> "port_security": {"type": {"key": "string",
>"min": 0,
>"max": "unlimited"}},
> "up": {"type": {"key": "boolean", "min": 0, "max": 1}},
> "enabled": {"type": {"key": "boolean", "min": 0, "max": 1}},
> "external_ids": {
> "type": {"key": "string", "value": "string",
>  "min": 0, "max": "unlimited"}}},
> "indexes": [["name"]],
> "isRoot": false},

We could add a new string column called "type".  Possible values could be:

  - (blank). The current behavior.

  - vtep : This logical port represents a connection to a logical switch
on a VTEP enabled switch

  - local : This logical port represents a connection to an OVS bridge
that exists locally to each ovn-controller.

Next we could have an "options" column  for key-value pairs of options
specific to the configured "type".  For vtep you'd have the physical and
logical switch names.  For local you'd have the network name and
optionally a VLAN ID.

-- 
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [ovn-controller-vtep V3 5/7] ovn-controller-vtep: Add gateway module.

[Russell Bryant]

On 07/14/2015 11:58 AM, Alex Wang wrote:
> 
> 
> On Tue, Jul 14, 2015 at 6:25 AM, Russell Bryant  > wrote:
> 
> Awesome work.  I plan to do a more in depth review but I had a quick
> comment about something I thought of last night.
> 
> On 07/13/2015 11:22 PM, Alex Wang wrote:
> > This commit adds the gateway module to ovn-controller-vtep.  The
> > module will register the physical switches to ovnsb as chassis and
> > constantly update the "logical_switches" column in Chassis table.
> >
> > Limitation:
> >
> > - Do not support reading multiple tunnel ips of physical switch.
> >
> > Signed-off-by: Alex Wang mailto:al...@nicira.com>>
> 
> > +/* If not already in 'lswitches', adds the logical 
> switch
> > + * to logical port map.  The logical port is defined as
> > + * {pswitch->name}_{ls->name}. */
> > +if (!smap_get(&lswitches, ls->name)) {
> > +char *lport = xasprintf("%s_%s", pswitch->name, 
> ls->name);
> > +
> > +smap_add(&lswitches, ls->name, lport);
> 
> I'm going to need a way to make sure that an OpenStack Neutron end user
> is not able to create ports with a name that could interfere with
> special port names.  I'm going to need special port names for the
> Neutron provider networks thing I'm working on, too.
> 
> A simple solution would be to adopt a convention where we prefix all
> special port names with "ovn_".  The Neutron driver could just reject
> any port names specified by users with that prefix and only use that for
> ports created automatically for a special purpose.
> 
> 
> 
> Could you explain more on what falls into the 'special port' category?
> only gateway logical ports or also the hv logical ports?  

The special logical ports are:

 - what you're adding, connection to logical switch on VTEP enabled
   switch

 - something i'm working on, connection to a physical network that is
   local to each host running ovn-controller (more on that in the link
   below)

> I think the
> ovn-controller just read the attached port from integration bridge without
> prefixing.  So, could it also be a collision there?

For some reason I was thinking that the user-supplied name for a Neutron
port was used as the OVN port name, but that's not correct.  User
supplied port names are not used for OVN port names so my concern
doesn't really make sense.

However, I still wonder if we should do something instead of encoding
the information in the name.  I posted some more thoughts in this message:

http://openvswitch.org/pipermail/dev/2015-July/057443.html

Take a look and see if that makes sense.

-- 
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [ovn-controller-vtep V3 7/7] ovn-controller-vtep: Add pipeline module.

[Alex Wang]

On Tue, Jul 14, 2015 at 7:19 AM, Liran Schour  wrote:

> "dev"  wrote on 14/07/2015 06:22:43 AM:
>
> > This commit adds the pipeline module to ovn-controller-vtep.  The
> > module will scan through the Binding table, and create the
> > Ucast_Macs_Remote in vtep database for each logical port's MACs in
> > the same logical datapath (same as logical switch for vtep).  Also
> > the module will create the physical locators to each HV chassis in
> > the same logical datapath.
> >
> > TODO:
> >
> > - vtep gateway will create entries in the "Ucast_Macs_Local" for
> >   each MAC learned.  ovn-controller-vtep should take advantage of
> >   this and notify the ovn-sb database in some way so that all HVs
> >   (in the same logical datapath) are aware of these MACs and will
> >   send all related packets to the vtep gateway.  We should achieve
> >   this in the near future.
> >
> > Signed-off-by: Alex Wang 
> >
>
> For clarification. Do you expect someone to add logical port with unknown
> MAC to the NB DB?
>


Yes, I expect that, since we want to assume there is only one VTEP gateway
for now.


If so why not to do the learning through the NB DB and add the learned MACs
> there. It will be projected to the SB DB by northd.
>
>

We discussed that.  The learned MACs could change very frequently, it is
too expensive to update it to northbond database.
So for now, we go for the simplest solution first.



> Thanks,
> - Liran
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [ovn-controller-vtep V3 5/7] ovn-controller-vtep: Add gateway module.

[Alex Wang]

On Tue, Jul 14, 2015 at 9:10 AM, Russell Bryant  wrote:

> On 07/14/2015 11:58 AM, Alex Wang wrote:
> >
> >
> > On Tue, Jul 14, 2015 at 6:25 AM, Russell Bryant  > > wrote:
> >
> > Awesome work.  I plan to do a more in depth review but I had a quick
> > comment about something I thought of last night.
> >
> > On 07/13/2015 11:22 PM, Alex Wang wrote:
> > > This commit adds the gateway module to ovn-controller-vtep.  The
> > > module will register the physical switches to ovnsb as chassis and
> > > constantly update the "logical_switches" column in Chassis table.
> > >
> > > Limitation:
> > >
> > > - Do not support reading multiple tunnel ips of physical switch.
> > >
> > > Signed-off-by: Alex Wang  al...@nicira.com>>
> >
> > > +/* If not already in 'lswitches', adds the
> logical switch
> > > + * to logical port map.  The logical port is
> defined as
> > > + * {pswitch->name}_{ls->name}. */
> > > +if (!smap_get(&lswitches, ls->name)) {
> > > +char *lport = xasprintf("%s_%s",
> pswitch->name, ls->name);
> > > +
> > > +smap_add(&lswitches, ls->name, lport);
> >
> > I'm going to need a way to make sure that an OpenStack Neutron end
> user
> > is not able to create ports with a name that could interfere with
> > special port names.  I'm going to need special port names for the
> > Neutron provider networks thing I'm working on, too.
> >
> > A simple solution would be to adopt a convention where we prefix all
> > special port names with "ovn_".  The Neutron driver could just reject
> > any port names specified by users with that prefix and only use that
> for
> > ports created automatically for a special purpose.
> >
> >
> >
> > Could you explain more on what falls into the 'special port' category?
> > only gateway logical ports or also the hv logical ports?
>
> The special logical ports are:
>
>  - what you're adding, connection to logical switch on VTEP enabled
>switch
>
>  - something i'm working on, connection to a physical network that is
>local to each host running ovn-controller (more on that in the link
>below)
>
> > I think the
> > ovn-controller just read the attached port from integration bridge
> without
> > prefixing.  So, could it also be a collision there?
>
> For some reason I was thinking that the user-supplied name for a Neutron
> port was used as the OVN port name, but that's not correct.  User
> supplied port names are not used for OVN port names so my concern
> doesn't really make sense.
>
>

Trying to understand, in your case, multiple HVs could each have a
connection to the same provider network right?



> However, I still wonder if we should do something instead of encoding
> the information in the name.  I posted some more thoughts in this message:
>
> http://openvswitch.org/pipermail/dev/2015-July/057443.html
>
> Take a look and see if that makes sense.
>
> --
> Russell Bryant
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] another provider network idea (was: [RFC] ovn: physical network integraiton (WIP))

[Ben Pfaff]

Please don't drop the list.

On Tue, Jul 14, 2015 at 11:24:36AM -0400, Aaron Conole wrote:
> On Tue, Jul 14, 2015 at 07:59:48AM -0700, Ben Pfaff wrote:
> > I think that the various issues with trying to treat a provider network
> > as a logical network are going to difficult to resolve.  I think that
> > they reflect a conceptual difference between OVN logical networks and
> > provider networks.  OVN knows the hosts on a logical network and where
> > they reside, but it doesn't know that for a provider network, and can't
> > do anything related to specific hosts except in the pathological case
> > where they reside on the same hypervisor.  Broadcast may be a problem,
> > but so is a simple output to any port: it's impossible unless the source
> > and destination ports are on the same hypervisor.  So my thought is that
> > modeling a provider network as an OVN logical network is unlikely to be
> > fruitful (unless we change the OVN logical network model significantly).
> > 
> > Here's an a strawman alternative.  Instead of representing a provider
> > network as a single logical network, represent it as a collection of
> > logical networks, one for each connected port.  Each of these logical
> > networks has only two ports, the VM's port plus a physical port on the
> > hypervisor where the VM resides (or more likely a patch port to the
> > bridge that contains the physical port; the other end of the patch port
> > can be an access port if it's a VLAN provider network).  It seems to me
> > that this models the situation more naturally.
> > 
> > Thoughts?
> 
> If I'm reading this correctly, it sounds as though OVS treats physical ports 
> as a single L2 segment; contrasted with a real switch where each port would be
> it's own L2 segment (and as a consequence, it's own logical L2 network). Is my
> analogy correct?

I don't understand the question.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] dpif-netdev: Translate Geneve options per-flow, not per-packet.

[Ben Pfaff]

On Tue, Jul 07, 2015 at 10:30:05PM -0700, Jesse Gross wrote:
> The kernel implementation of Geneve options stores the TLV option
> data in the flow exactly as received, without any further parsing.
> This is then translated to known options for the purposes of matching
> on flow setup (which will then install a datapath flow in the form
> the kernel is expecting).
> 
> The userspace implementation behaves a little bit differently - it
> looks up known options as each packet is received. The reason for this
> is there is a much tighter coupling between datapath and flow translation
> and the representation is generally expected to be the same. This works
> but it incurs work on a per-packet basis that could be done per-flow
> instead.
> 
> This introduces a small translation step for Geneve packets between
> datapath and flow lookup for the userspace datapath in order to
> allow the same kind of processing that the kernel does.
> 
> Signed-off-by: Jesse Gross 

Here's a comment for struct tun_metadata with a little more detail, to
try to make sure I understand it correctly:

/* Tunnel option data, plus metadata to aid in their interpretation.
 *
 * Option data exists in two forms.  Most of the time, the code path we're in
 * determines which form is in use; in the occasional case where there is
 * ambiguity, code can distinguish based on whether 'tab' is nonnull.  The
 * two cases are:
 *
 * - In places where we are doing per-packet fast path processing
 *   (i.e. userspace datapath), 'opts.gnv' is raw packet data from the
 *   tunnel header and 'present.len' indicates the length of the data
 *   stored there.  'tab' is NULL.
 *
 * - In all other cases, we are doing flow-based processing (such as during
 *   upcalls) and options are reordered into pre-allocated locations.
 *   'present.map' is indexed by type, that is, by the  in
 *   TUN_METADATA, so that e.g. TUN_METADATA5 is present if 'present.map
 *   & (1ULL << 5)' is nonzero.  The actual data for TUN_METADATA5, if
 *   present, might be anywhere in 'opts.u8' (not necessarily even
 *   contiguous), and finding it requires referring to 'tab', which is
 *   nonnull.
 */

Similarly for struct odp_flow_key_parms:

/* Some fields have different representation for flow setup and per-
 * packet processing (i.e. different between ofproto-dpif and userspace
 * datapath). This flag indicates that these fields are already in the
 * per-packet format rather than per-flow, which is the normal input.
 * In particular, if false, the struct tun_metadata in the input flow is
 * in the per-flow format (using 'present.map' and 'opts.u8'); if true,
 * struct tun_metadata is in the per-packet format (using 'present.len'
 * and 'opts.gnv'). */
bool udpif_no_xlate;

Do we need 'udpif_no_xlate'?  That is, can odp_flow_key_from_flow()
check whether flow->tun.metadata.tab != NULL to distinguish the cases?

s/uncoverted/unconverted/ (or maybe just s/uncoverted/raw/) in comment
on tun_metadata_from_geneve_header().

dpif_netdev_mask_from_nlattrs() adds an extra blank line before
} else {

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/2] dpif-netdev: Don't use designated initializers.

[Ben Pfaff]

On Tue, Jul 14, 2015 at 08:27:15AM -0700, Jesse Gross wrote:
> On Tue, Jul 14, 2015 at 8:18 AM, Gurucharan Shetty  wrote:
> > On Mon, Jul 13, 2015 at 2:12 PM, Jesse Gross  wrote:
> >> On Fri, Jul 10, 2015 at 9:26 PM, Gurucharan Shetty  
> >> wrote:
> >>> MSVC 2013 does not like designated initializers when
> >>> structs are initialized inside structs.
> >>>
> >>> Signed-off-by: Gurucharan Shetty 
> >>
> >> This looks fine to me, although there are several other instances of
> >> this pattern in other places. Are the ones in ofproto/ofproto-dpif.c,
> >> for example, which also initialize .support different enough that they
> >> slip into some weird corner case that is OK?
> > I started looking more at the reason on why the change in dpif-netdev
> > causes failures and why the use of designated initializers in
> > ofproto-dpif does not. So one thing that I have in public domain is
> > this: 
> > https://connect.microsoft.com/VisualStudio/feedback/details/805981/msvc-2013-c99-designated-initializers-cannot-initialize-unions-within-structs
> >
> > Based on the above, my first feeling is that because struct flow has
> > unions inside it, that may be the reason. I also noticed that
> > Microsoft had marked the issue as resolved. So I downloaded their
> > latest upgrade pack "visual studio 2103 update 4" and that does not
> > have any problems. Looks like Appveyor uses the same upgrade pack and
> > so we do not see the same problem at appveyor anymore.
> >
> > So I will just drop this patch and use the latest MSVC 2013 instead.
> 
> Awesome!

Yeah, this is the perfect solution.  Thanks!

Guru: should we add a note to the Windows build instructions saying that
you need a particular MSVC build?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] Revert "ofctrl: Don't use designated initializers."

[Ben Pfaff]

This reverts commit 0b090f2263807e25be14f90a287c4bfdee2d82ec.  When that
commit was applied, we did not know of a fix for the MSVC bug that it
avoided, but now we know that sufficiently new MSVC 2013 supports this
feature.

CC: Gurucharan Shetty 
Signed-off-by: Ben Pfaff 
---
 ovn/controller/ofctrl.c | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/ovn/controller/ofctrl.c b/ovn/controller/ofctrl.c
index 2c424a6..843e1a1 100644
--- a/ovn/controller/ofctrl.c
+++ b/ovn/controller/ofctrl.c
@@ -406,12 +406,12 @@ ofctrl_update_flows(void)
 if (!d) {
 /* Installed flow is no longer desirable.  Delete it from the
  * switch and from installed_flows. */
-struct ofputil_flow_mod fm;
-memset(&fm, 0, sizeof fm);
-fm.match = i->match;
-fm.priority = i->priority;
-fm.table_id = i->table_id;
-fm.command = OFPFC_DELETE_STRICT;
+struct ofputil_flow_mod fm = {
+.match = i->match,
+.priority = i->priority,
+.table_id = i->table_id,
+.command = OFPFC_DELETE_STRICT,
+};
 queue_flow_mod(&fm);
 ovn_flow_log(i, "removing");
 
@@ -421,14 +421,14 @@ ofctrl_update_flows(void)
 if (!ofpacts_equal(i->ofpacts, i->ofpacts_len,
d->ofpacts, d->ofpacts_len)) {
 /* Update actions in installed flow. */
-struct ofputil_flow_mod fm;
-memset(&fm, 0, sizeof fm);
-fm.match = i->match;
-fm.priority = i->priority;
-fm.table_id = i->table_id;
-fm.ofpacts = d->ofpacts;
-fm.ofpacts_len = d->ofpacts_len;
-fm.command = OFPFC_MODIFY_STRICT;
+struct ofputil_flow_mod fm = {
+.match = i->match,
+.priority = i->priority,
+.table_id = i->table_id,
+.ofpacts = d->ofpacts,
+.ofpacts_len = d->ofpacts_len,
+.command = OFPFC_MODIFY_STRICT,
+};
 queue_flow_mod(&fm);
 ovn_flow_log(i, "updating");
 
@@ -451,14 +451,14 @@ ofctrl_update_flows(void)
 struct ovn_flow *d;
 HMAP_FOR_EACH_SAFE (d, next, hmap_node, &desired_flows) {
 /* Send flow_mod to add flow. */
-struct ofputil_flow_mod fm;
-memset(&fm, 0, sizeof fm);
-fm.match = d->match;
-fm.priority = d->priority;
-fm.table_id = d->table_id;
-fm.ofpacts = d->ofpacts;
-fm.ofpacts_len = d->ofpacts_len;
-fm.command = OFPFC_ADD;
+struct ofputil_flow_mod fm = {
+.match = d->match,
+.priority = d->priority,
+.table_id = d->table_id,
+.ofpacts = d->ofpacts,
+.ofpacts_len = d->ofpacts_len,
+.command = OFPFC_ADD,
+};
 queue_flow_mod(&fm);
 ovn_flow_log(d, "adding");
 
-- 
2.1.3

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] CodingStyle: Remove designated initialzers as acceptable.

[Ben Pfaff]

On Tue, Jul 14, 2015 at 08:20:28AM -0700, Gurucharan Shetty wrote:
> On Sat, Jul 11, 2015 at 9:56 AM, Ben Pfaff  wrote:
> > On Fri, Jul 10, 2015 at 09:26:07PM -0700, Gurucharan Shetty wrote:
> >> MSVC 2013 does not like designated initializers when
> >> structs are initialized inside structs.
> >>
> >> Signed-off-by: Gurucharan Shetty 
> >
> > Ugh.
> >
> > Acked-by: Ben Pfaff 
> >
> > (Patch 1 looked OK too but I'm not really an expert on that code anymore
> > so I'd prefer to get a review from someone else.)
> 
> I decided to drop this series as the issue of designated initializers
> seems to be fixed in MSVC 2013 "update 4". The public information that
> exists is here:
> https://connect.microsoft.com/VisualStudio/feedback/details/805981/msvc-2013-c99-designated-initializers-cannot-initialize-unions-within-structs

Does that mean that we can revert the patch that removed some of these?
http://openvswitch.org/pipermail/dev/2015-July/057449.html
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] Revert "ofctrl: Don't use designated initializers."

[Gurucharan Shetty]

On Tue, Jul 14, 2015 at 12:50 PM, Ben Pfaff  wrote:
> This reverts commit 0b090f2263807e25be14f90a287c4bfdee2d82ec.  When that
> commit was applied, we did not know of a fix for the MSVC bug that it
> avoided, but now we know that sufficiently new MSVC 2013 supports this
> feature.
>
> CC: Gurucharan Shetty 
> Signed-off-by: Ben Pfaff 
Acked-by: Gurucharan Shetty 

> ---
>  ovn/controller/ofctrl.c | 44 ++--
>  1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/ovn/controller/ofctrl.c b/ovn/controller/ofctrl.c
> index 2c424a6..843e1a1 100644
> --- a/ovn/controller/ofctrl.c
> +++ b/ovn/controller/ofctrl.c
> @@ -406,12 +406,12 @@ ofctrl_update_flows(void)
>  if (!d) {
>  /* Installed flow is no longer desirable.  Delete it from the
>   * switch and from installed_flows. */
> -struct ofputil_flow_mod fm;
> -memset(&fm, 0, sizeof fm);
> -fm.match = i->match;
> -fm.priority = i->priority;
> -fm.table_id = i->table_id;
> -fm.command = OFPFC_DELETE_STRICT;
> +struct ofputil_flow_mod fm = {
> +.match = i->match,
> +.priority = i->priority,
> +.table_id = i->table_id,
> +.command = OFPFC_DELETE_STRICT,
> +};
>  queue_flow_mod(&fm);
>  ovn_flow_log(i, "removing");
>
> @@ -421,14 +421,14 @@ ofctrl_update_flows(void)
>  if (!ofpacts_equal(i->ofpacts, i->ofpacts_len,
> d->ofpacts, d->ofpacts_len)) {
>  /* Update actions in installed flow. */
> -struct ofputil_flow_mod fm;
> -memset(&fm, 0, sizeof fm);
> -fm.match = i->match;
> -fm.priority = i->priority;
> -fm.table_id = i->table_id;
> -fm.ofpacts = d->ofpacts;
> -fm.ofpacts_len = d->ofpacts_len;
> -fm.command = OFPFC_MODIFY_STRICT;
> +struct ofputil_flow_mod fm = {
> +.match = i->match,
> +.priority = i->priority,
> +.table_id = i->table_id,
> +.ofpacts = d->ofpacts,
> +.ofpacts_len = d->ofpacts_len,
> +.command = OFPFC_MODIFY_STRICT,
> +};
>  queue_flow_mod(&fm);
>  ovn_flow_log(i, "updating");
>
> @@ -451,14 +451,14 @@ ofctrl_update_flows(void)
>  struct ovn_flow *d;
>  HMAP_FOR_EACH_SAFE (d, next, hmap_node, &desired_flows) {
>  /* Send flow_mod to add flow. */
> -struct ofputil_flow_mod fm;
> -memset(&fm, 0, sizeof fm);
> -fm.match = d->match;
> -fm.priority = d->priority;
> -fm.table_id = d->table_id;
> -fm.ofpacts = d->ofpacts;
> -fm.ofpacts_len = d->ofpacts_len;
> -fm.command = OFPFC_ADD;
> +struct ofputil_flow_mod fm = {
> +.match = d->match,
> +.priority = d->priority,
> +.table_id = d->table_id,
> +.ofpacts = d->ofpacts,
> +.ofpacts_len = d->ofpacts_len,
> +.command = OFPFC_ADD,
> +};
>  queue_flow_mod(&fm);
>  ovn_flow_log(d, "adding");
>
> --
> 2.1.3
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] INSTALL.Windows.md: Update the minimum required compiler.

[Gurucharan Shetty]

MSVC 2013 update 4 was released in Nov 2014. Its release notes
says that it has fixed the problem wherein using designated
initializers to initialize unions within structs would
fail to compile.

Using designated initializers is useful in OVS and so this commit
updates the minimum required compiler for Windows.

Signed-off-by: Gurucharan Shetty 
---
 INSTALL.Windows.md |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/INSTALL.Windows.md b/INSTALL.Windows.md
index 6d870ed..889bb0b 100644
--- a/INSTALL.Windows.md
+++ b/INSTALL.Windows.md
@@ -28,9 +28,9 @@ the following entry in /etc/fstab - 'C:/MinGW /mingw'.
 * Install the latest Python 2.x from python.org and verify that its path is
 part of Windows' PATH environment variable.
 
-* You will need at least Visual Studio 2013 to compile userspace binaries. In
-addition to that, if you want to compile the kernel module you will also need 
to
-install Windows Driver Kit (WDK) 8.1 Update.
+* You will need at least Visual Studio 2013 (update 4) to compile userspace
+binaries.  In addition to that, if you want to compile the kernel module you
+will also need to install Windows Driver Kit (WDK) 8.1 Update.
 
 It is important to get the Visual Studio related environment variables and to
 have the $PATH inside the bash to point to the proper compiler and linker. One
-- 
1.7.9.5

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] INSTALL.Windows.md: Update the minimum required compiler.

[Eitan Eliahu]

Acked-by: Eitan Eliahu 

It would be good if we could verify that the driver is compiled and run when 
compiled with VS Update 4 and Winddk 8.1.
Thanks
Eitan

-Original Message-
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Gurucharan Shetty
Sent: Tuesday, July 14, 2015 11:57 AM
To: dev@openvswitch.org
Cc: Gurucharan Shetty
Subject: [ovs-dev] [PATCH] INSTALL.Windows.md: Update the minimum required 
compiler.

MSVC 2013 update 4 was released in Nov 2014. Its release notes says that it has 
fixed the problem wherein using designated initializers to initialize unions 
within structs would fail to compile.

Using designated initializers is useful in OVS and so this commit updates the 
minimum required compiler for Windows.

Signed-off-by: Gurucharan Shetty 
---
 INSTALL.Windows.md |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/INSTALL.Windows.md b/INSTALL.Windows.md index 6d870ed..889bb0b 
100644
--- a/INSTALL.Windows.md
+++ b/INSTALL.Windows.md
@@ -28,9 +28,9 @@ the following entry in /etc/fstab - 'C:/MinGW /mingw'.
 * Install the latest Python 2.x from python.org and verify that its path is  
part of Windows' PATH environment variable.
 
-* You will need at least Visual Studio 2013 to compile userspace binaries. In 
-addition to that, if you want to compile the kernel module you will also need 
to -install Windows Driver Kit (WDK) 8.1 Update.
+* You will need at least Visual Studio 2013 (update 4) to compile 
+userspace binaries.  In addition to that, if you want to compile the 
+kernel module you will also need to install Windows Driver Kit (WDK) 8.1 
Update.
 
 It is important to get the Visual Studio related environment variables and to  
have the $PATH inside the bash to point to the proper compiler and linker. One
--
1.7.9.5

___
dev mailing list
dev@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailman_listinfo_dev&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=CWsgHUxi6ExLXY798tmo3LJ4e3geGYp56lkcH-5cLCY&m=j7iHpo0VgVdmCO_wv2COlEnWbdn-uyYnVKITELN9pcw&s=zM2m3mB4cNPSETWfrgDi3I-HnJJgvSwU8eNRJrCXZMc&e=
 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] Revert "ofctrl: Don't use designated initializers."

[Ben Pfaff]

On Tue, Jul 14, 2015 at 01:04:36PM -0700, Gurucharan Shetty wrote:
> On Tue, Jul 14, 2015 at 12:50 PM, Ben Pfaff  wrote:
> > This reverts commit 0b090f2263807e25be14f90a287c4bfdee2d82ec.  When that
> > commit was applied, we did not know of a fix for the MSVC bug that it
> > avoided, but now we know that sufficiently new MSVC 2013 supports this
> > feature.
> >
> > CC: Gurucharan Shetty 
> > Signed-off-by: Ben Pfaff 
> Acked-by: Gurucharan Shetty 

Thanks, applied to master.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] Add 'name' field to Logical Router

[Ben Pfaff]

On Wed, Jul 08, 2015 at 09:44:33AM +0300, Gal Sagie wrote:
> Adding a name identifier will increase convinence
> for Openstack (or Other CMS) that want to identify
> the logical router (or store the CMS id in the router name)
> 
> Signed-off-by: Gal Sagie 
> Signed-off-by: Gal Sagie 

Applied, thanks!
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] Add 'name' field to Logical Router

[Ben Pfaff]

On Wed, Jul 08, 2015 at 09:26:10AM -0400, Russell Bryant wrote:
> On 07/08/2015 02:44 AM, Gal Sagie wrote:
> > Adding a name identifier will increase convinence
> > for Openstack (or Other CMS) that want to identify
> > the logical router (or store the CMS id in the router name)
> > 
> > Signed-off-by: Gal Sagie 
> > Signed-off-by: Gal Sagie 
> 
> This seems reasonable to me.  It seems odd to have two s-o-b headers,
> though.  Maybe pick one?

Good point.  I took the one that matched AUTHORS and the From address.

> Acked-by: Russell Bryant 

Thanks, I added the ack.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVN - L3 Design

[Ben Pfaff]

On Wed, Jul 08, 2015 at 04:23:09PM +0300, Gal Sagie wrote:
> First, i think everyone would love to hear if there are any plans or any
> first ideas
> regarding the L3 design.
> 
> Second, i would like to talk about what currently is available in the
> schema and how it differs
> from Openstack Neutron.
> 
> 1. The logical router port has no interface IP, from the description i
> understand that the
> 'network' is meant to describe the entire subnet range but we still
> need an IP that is used
> as the default gateway of the logical switch (or network in terms of
> neutron)
> (This IP is configurable in Neutron)

This does seem like an omission.  I'll send a patch.

> 2. Currently there is no IP information for logical ports in the NB schema

Is it useful?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] ovn-nb: Add per-port IP addresses to routers.

[Ben Pfaff]

A router needs one IP address per port, not just one for the whole router.

Reported-by: Gal Sagie 
Reported-at: http://openvswitch.org/pipermail/dev/2015-July/057242.html
Signed-off-by: Ben Pfaff 
---
 ovn/ovn-nb.ovsschema |  1 -
 ovn/ovn-nb.xml   | 13 -
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
index 8fe378a..40bba97 100644
--- a/ovn/ovn-nb.ovsschema
+++ b/ovn/ovn-nb.ovsschema
@@ -65,7 +65,6 @@
"refType": "weak"},
"min": 0,
"max": "unlimited"}},
-"ip": {"type": "string"},
 "default_gw": {"type": {"key": "string", "min": 0, "max": 1}},
 "external_ids": {
 "type": {"key": "string", "value": "string",
diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
index 266e6a4..59ec3d2 100644
--- a/ovn/ovn-nb.xml
+++ b/ovn/ovn-nb.xml
@@ -281,13 +281,6 @@
   table="Logical_Router_Port"/> or it will automatically be deleted.
 
 
-
-  The logical router's own IP address.  The logical router uses this
-  address for ICMP replies (e.g. network unreachable messages) and other
-  traffic that it originates and responds to traffic destined to this
-  address (e.g. ICMP echo requests).
-
-
 
   IP address to use as default gateway, if any.
 
@@ -316,8 +309,10 @@
 
 
 
-  The IP network and netmask of the network on the router port.  Used for
-  routing.
+  The IP address of the router and the netmask.  For example,
+  192.168.0.1/24 indicates that the router's IP address is
+  192.168.0.1 and that packets destined to 192.168.0.x should be
+  routed to this port.
 
 
 
-- 
2.1.3

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [v2 1/2] perf-counter: simplify the performance macro

[Ben Pfaff]

On Wed, Jul 08, 2015 at 02:17:56PM -0700, Andy Zhou wrote:
> Replace the original PERF_FUNCTION_BEGIN and PERF_FUNCTION_END
> pair with a single PERF macro. This design is also more flexible,
> removing the restriction of have only one measurement per function.
> 
> The next patch will make use of this macro.
> 
> Signed-off-by: Andy Zhou 
> 
> ---
> v1 -> v2:  Drop perf-counter.c clean up changes.

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [v2 2/2] ovsdb: Add per transaction commit instruction counter

[Ben Pfaff]

On Wed, Jul 08, 2015 at 02:17:57PM -0700, Andy Zhou wrote:
> Measure user space only instruction counters for commit each
> transaction. This measurement is mainly useful for
> tuning OVSDB internal implementation, such as how OVSDB scales over
> number of client connections.
> 
> A simple usage example:
> 
> ovs-appctl -t ovsdb-server ovsdb-server/perf-counters-clear
> ovs-vsctl add-port br0 p3
> ovs-appctl -t ovsdb-server ovsdb-server/perf-counters-show
> ovsdb_txn_commit2  906922 453461.0
> 
> The commands above show that the 'add-port br p3' command caused ovsdb
> to execute 2 transactions. Each transaction takes 453461 instructions,
> total 906922 instructions. The number will vary based on number of
> ovsdb clients connected.
> 
> Signed-off-by: Andy Zhou 
> Acked-by: Ben Pfaff 

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVN - QoS (Neutron API)

[Ben Pfaff]

On Thu, Jul 09, 2015 at 01:14:23PM +0300, Gal Sagie wrote:
> Hello all,
> 
> As of Liberty, neutron will support a QoS API which can be configured on
> the logical ports.
> (Currently only bandwidth limiting will be supported)
> 
> I would like to offer to implement this back-to-back in Neutron OVN plugin
> and in OVN.
> 
> For this feature we would need to extend the OVN NB API to include QoS
> Policy profile table
> and another table for QoS rules which are attached to the policy profile.
> (Currently we will only support the bandwidth limiting rule type)
> 
> Logical Ports can be attached with QoS profiles.
> 
> I suggest that currently this will be directly mapped to the SB schema by
> northd (and in the future this can be extended to use Openflow Metering
> flows when this is fully supported in OVS)
> 
> The local OVN-Controller can then use OVSDB for the local vswitch to
> configure the current
> rules (similar work that we do in Neutron with the L2 Agent)
> 
> If the general idea is good, i can take this task on myself and
> describe the schema in more details.
> 
> Please let me know,

This sounds reasonable to me.  I see that you already sent out a draft
for the NB schema component.  I'll take a look.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC PATCH v2 3/7] flow: Always inline miniflows.

[Ben Pfaff]

On Fri, Jul 10, 2015 at 10:35:21AM -0700, Jarno Rajahalme wrote:
> Now that performance critical code already inlines miniflows and
> minimasks, we can simplify struct miniflow by always dynamically
> allocating miniflows and minimasks to the correct size.  This changes
> the struct minimatch to always contain pointers to its miniflow and
> minimask.
> 
> Signed-off-by: Jarno Rajahalme 

I like simplifying things so that two possibilities become one.  It's
nice.

I see two possible ways to simplify this, each with its own tradeoffs:

   1. The way that you did it, which means that one must always
  either dynamically allocate struct miniflow to a proper size
  or ensure that there's enough space for the maximum size flow
  immediately following struct miniflow.  

   2. Change struct miniflow to:

struct miniflow {
uint64_t map;
uint64_t *values;
};

  With this strategy, there's no need to dynamically allocate
  struct miniflow itself, so it can be directly embedded in
  larger structures instead of via pointer.  The usual time cost
  of accessing miniflow data is again one pointer dereference
  (of 'values').

  This can be kind of nice because you're not fighting with the
  compiler to put data in the right place.

Either way, the usual time cost of accessing miniflow data is one
pointer dereference (in case #1, from whatever contains the miniflow; in
case #2, dereference of 'values'), and the usual space cost of embedding
a miniflow is one pointer (although in case #1 the pointer is in what
contains the miniflow and in case #2 the pointer is in the miniflow
itself).

Anyway, I wanted to make sure that you considered both of these
solutions and decided that #1 was better.  If so:

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [v2 2/2] ovsdb: Add per transaction commit instruction counter

[Ben Pfaff]

On Tue, Jul 14, 2015 at 03:57:15PM -0700, Ben Pfaff wrote:
> On Wed, Jul 08, 2015 at 02:17:57PM -0700, Andy Zhou wrote:
> > Measure user space only instruction counters for commit each
> > transaction. This measurement is mainly useful for
> > tuning OVSDB internal implementation, such as how OVSDB scales over
> > number of client connections.
> > 
> > A simple usage example:
> > 
> > ovs-appctl -t ovsdb-server ovsdb-server/perf-counters-clear
> > ovs-vsctl add-port br0 p3
> > ovs-appctl -t ovsdb-server ovsdb-server/perf-counters-show
> > ovsdb_txn_commit2  906922 453461.0
> > 
> > The commands above show that the 'add-port br p3' command caused ovsdb
> > to execute 2 transactions. Each transaction takes 453461 instructions,
> > total 906922 instructions. The number will vary based on number of
> > ovsdb clients connected.
> > 
> > Signed-off-by: Andy Zhou 
> > Acked-by: Ben Pfaff 
> 
> Acked-by: Ben Pfaff 

Actually I have to take this back, because this commit causes tons of
test failures for me:

   Subject: [openvswitch 2.4.90] testsuite: 103 104 105 106 107 108 118 
1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1293 
1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1309 1310 1311 1312 
1313 1314 1315 1316 1317 1318 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 
1330 1331 1332 1333 1334 1335 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 
1349 1350 1351 1383 1384 1390 1394 1396 1450 1451 1452 1454 1455 1457 1458 1468 
1469 1470 1471 1472 1473 1474 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 
1486 1487 1488 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 
1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 
1571 1572 1573 1574 1575 1576 1577 1580 1581 1582 1616 1617 1618 1619 1620 1621 
1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 
1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 failed

The tests all seem to fail because of segfaults in ovsdb-server.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] ovs-ofctl.8: Specify correct variable in "snoop" description.

[Justin Pettit]

Signed-off-by: Justin Pettit 
---
 utilities/ovs-ofctl.8.in |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/utilities/ovs-ofctl.8.in b/utilities/ovs-ofctl.8.in
index e3436af..4c91720 100644
--- a/utilities/ovs-ofctl.8.in
+++ b/utilities/ovs-ofctl.8.in
@@ -467,7 +467,7 @@ Connects to \fIswitch\fR and prints to the console all 
OpenFlow
 messages received.  Unlike other \fBovs\-ofctl\fR commands, if
 \fIswitch\fR is the name of a bridge, then the \fBsnoop\fR command
 connects to a Unix domain socket named
-\fB@RUNDIR@/\fIbridge\fB.snoop\fR.  \fBovs\-vswitchd\fR listens on
+\fB@RUNDIR@/\fIswitch\fB.snoop\fR.  \fBovs\-vswitchd\fR listens on
 such a socket for each bridge and sends to it all of the OpenFlow
 messages sent to or received from its configured OpenFlow controller.
 Thus, this command can be used to view OpenFlow protocol activity
-- 
1.7.5.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 1/2] ovn: Minor cleanups in "physical" component comments.

[Justin Pettit]

Signed-off-by: Justin Pettit 
---
 ovn/controller/physical.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index dce0c2f..9e7f2f4 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -92,7 +92,7 @@ physical_run(struct controller_ctx *ctx)
  * 64 for logical-to-physical translation. */
 const struct sbrec_binding *binding;
 SBREC_BINDING_FOR_EACH (binding, ctx->ovnsb_idl) {
-/* Find the Openflow port for the logical port, as 'ofport'.  If it's
+/* Find the OpenFlow port for the logical port, as 'ofport'.  If it's
  * on a remote chassis, this is the OpenFlow port for the tunnel to
  * that chassis (and set 'local' to false).  Otherwise, if it's on the
  * chassis we're managing, this is the OpenFlow port for the vif itself
@@ -134,13 +134,14 @@ physical_run(struct controller_ctx *ctx)
 
 struct match match;
 if (local) {
-/*
- * Packets that arrive from a vif can belong to a VM or
+/* Packets that arrive from a vif can belong to a VM or
  * to a container located inside that VM. Packets that
  * arrive from containers have a tag (vlan) associated with them.
- *
- * Table 0, Priority 150 and 100.
+ */
+
+/* Table 0, Priority 150 and 100.
  * ==
+ *
  * Priority 150 is for traffic belonging to containers. For such
  * traffic, match on the tags and then strip the tag.
  * Priority 100 is for traffic belonging to VMs.
-- 
1.7.5.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/2] ovn: Minor cleanups in "physical" component comments.

[Justin Pettit]

There's only this one patch in this "series".  I forgot to clean that up before 
I sent it.

--Justin


> On Jul 14, 2015, at 5:31 PM, Justin Pettit  wrote:
> 
> Signed-off-by: Justin Pettit 
> ---
> ovn/controller/physical.c |   11 ++-
> 1 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
> index dce0c2f..9e7f2f4 100644
> --- a/ovn/controller/physical.c
> +++ b/ovn/controller/physical.c
> @@ -92,7 +92,7 @@ physical_run(struct controller_ctx *ctx)
>  * 64 for logical-to-physical translation. */
> const struct sbrec_binding *binding;
> SBREC_BINDING_FOR_EACH (binding, ctx->ovnsb_idl) {
> -/* Find the Openflow port for the logical port, as 'ofport'.  If it's
> +/* Find the OpenFlow port for the logical port, as 'ofport'.  If it's
>  * on a remote chassis, this is the OpenFlow port for the tunnel to
>  * that chassis (and set 'local' to false).  Otherwise, if it's on the
>  * chassis we're managing, this is the OpenFlow port for the vif 
> itself
> @@ -134,13 +134,14 @@ physical_run(struct controller_ctx *ctx)
> 
> struct match match;
> if (local) {
> -/*
> - * Packets that arrive from a vif can belong to a VM or
> +/* Packets that arrive from a vif can belong to a VM or
>  * to a container located inside that VM. Packets that
>  * arrive from containers have a tag (vlan) associated with them.
> - *
> - * Table 0, Priority 150 and 100.
> + */
> +
> +/* Table 0, Priority 150 and 100.
>  * ==
> + *
>  * Priority 150 is for traffic belonging to containers. For such
>  * traffic, match on the tags and then strip the tag.
>  * Priority 100 is for traffic belonging to VMs.
> -- 
> 1.7.5.4
> 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] automake: Cleanup to allow make distcheck to succeed.

[Aaron Conole]

For some time, it seems that the distcheck make target has not functioned
properly. This patch works around the automake imposed  distcheck read-only 
directory, as well as signaling to travis-ci that sudo is required (which is 
required for new github forks as of 2015-01-01).

Tested on travis-ci, and on a ubuntu 14.04LTS system.
---
NOTE: This is a re-submission because it seems my email configuration was not
correct. I hope this gets through.

Signed-off-by: Aaron Conole 
---
 .travis.yml  | 2 ++
 AUTHORS  | 1 +
 Makefile.am  | 2 +-
 datapath-windows/include/automake.mk | 2 +-
 lib/automake.mk  | 9 ++---
 ovsdb/automake.mk| 4 ++--
 tests/automake.mk| 2 ++
 vtep/automake.mk | 2 +-
 8 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 36d95bd..2c0fd96 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -3,6 +3,8 @@ compiler:
   - gcc
   - clang
 
+sudo: true
+
 before_install: ./.travis/prepare.sh
 
 env:
diff --git a/AUTHORS b/AUTHORS
index e81ff17..a797baa 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -23,6 +23,7 @@ Ariel Tubaltsev atubalt...@vmware.com
 Arun Sharma arun.sha...@calsoftinc.com
 Aryan TaheriMonfaredaryan.taherimonfa...@uis.no
 Ashwin Swaminathan  ashwi...@arista.com
+Aaron Conoleaa...@bytheb.org
 Ben Pfaff   b...@nicira.com
 Billy O'Mahony  billy.o.mah...@intel.com
 Brian Krugerbkruger+ovs...@gmail.com
diff --git a/Makefile.am b/Makefile.am
index a659814..209e4dc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -44,7 +44,7 @@ endif
 if WIN32
 psep=";"
 else
-psep=":"
+psep=:
 endif
 # PYTHONDONTWRITEBYTECODE=yes keeps Python from creating .pyc and .pyo
 # files.  Creating .py[co] works OK for any given version of Open
diff --git a/datapath-windows/include/automake.mk 
b/datapath-windows/include/automake.mk
index 31f2fe2..9ab6c1f 100644
--- a/datapath-windows/include/automake.mk
+++ b/datapath-windows/include/automake.mk
@@ -3,7 +3,7 @@ BUILT_SOURCES += 
$(srcdir)/datapath-windows/include/OvsDpInterface.h
 $(srcdir)/datapath-windows/include/OvsDpInterface.h: \
  datapath/linux/compat/include/linux/openvswitch.h \
  build-aux/extract-odp-netlink-windows-dp-h
-   $(AM_V_GEN)sed -f $(srcdir)/build-aux/extract-odp-netlink-windows-dp-h 
< $< > $@
+   $(AM_V_GEN)chmod u+w $(dir $@) && sed -f 
$(srcdir)/build-aux/extract-odp-netlink-windows-dp-h < $< > $@
 
 EXTRA_DIST += $(srcdir)/build-aux/extract-odp-netlink-windows-dp-h
 
diff --git a/lib/automake.mk b/lib/automake.mk
index f72eb32..560cbb0 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -446,7 +446,8 @@ OVSIDL_BUILT += lib/vswitch-idl.c lib/vswitch-idl.h 
lib/vswitch-idl.ovsidl
 
 EXTRA_DIST += lib/vswitch-idl.ann
 $(srcdir)/lib/vswitch-idl.ovsidl: vswitchd/vswitch.ovsschema 
lib/vswitch-idl.ann
-   $(AM_V_GEN)$(OVSDB_IDLC) annotate $(srcdir)/vswitchd/vswitch.ovsschema 
$(srcdir)/lib/vswitch-idl.ann > $@.tmp && mv $@.tmp $@
+   $(AM_V_GEN)chmod u+w $(dir $@) && $(OVSDB_IDLC) annotate 
$(srcdir)/vswitchd/vswitch.ovsschema $(srcdir)/lib/vswitch-idl.ann > $@.tmp && 
mv $@.tmp $@
+CLEANFILES += $(srcdir)/lib/vswitch-idl.ovsidl $(OVSIDL_BUILT)
 
 lib/dirs.c: lib/dirs.c.in Makefile
$(AM_V_GEN)($(ro_c) && sed < $(srcdir)/lib/dirs.c.in \
@@ -484,13 +485,15 @@ lib/ofp-errors.inc: lib/ofp-errors.h 
include/openflow/openflow-common.h \
$(srcdir)/include/openflow/openflow-common.h > $@.tmp && \
mv $@.tmp $@
 lib/ofp-errors.c: lib/ofp-errors.inc
-EXTRA_DIST += build-aux/extract-ofp-errors
+EXTRA_DIST += build-aux/extract-ofp-errors $(srcdir)/lib/ofp-errors.c
+CLEANFILES += lib/ofp-errors.inc
 
 lib/ofp-msgs.inc: lib/ofp-msgs.h $(srcdir)/build-aux/extract-ofp-msgs
$(AM_V_GEN)$(run_python) $(srcdir)/build-aux/extract-ofp-msgs \
$(srcdir)/lib/ofp-msgs.h $@ > $@.tmp && mv $@.tmp $@
 lib/ofp-msgs.c: lib/ofp-msgs.inc
-EXTRA_DIST += build-aux/extract-ofp-msgs
+EXTRA_DIST += build-aux/extract-ofp-msgs $(srcdir)/lib/ofp-msgs.c
+CLEANFILES += lib/ofp-msgs.inc
 
 INSTALL_DATA_LOCAL += lib-install-data-local
 lib-install-data-local:
diff --git a/ovsdb/automake.mk b/ovsdb/automake.mk
index de7c5e0..b17965b 100644
--- a/ovsdb/automake.mk
+++ b/ovsdb/automake.mk
@@ -79,9 +79,9 @@ DISTCLEANFILES += ovsdb/ovsdb-idlc
 SUFFIXES += .ovsidl .ovsschema
 OVSDB_IDLC = $(run_python) $(srcdir)/ovsdb/ovsdb-idlc.in
 .ovsidl.c:
-   $(AM_V_GEN)$(OVSDB_IDLC) c-idl-source $< > $@.tmp && mv $@.tmp $@
+   $(AM_V_GEN)$(OVSDB_IDLC) c-idl-source $< > $@.tmp && mv -f $@.tmp $@
 .ovsidl.h:
-   $(AM_V_GEN)$(OVSDB_IDLC) c-idl-header $< > $@.tmp && mv $@.tmp $@
+   $(AM_V_GEN)$(OVSDB_IDLC) c-idl-header $< > $@.tmp && mv -f $@.tmp $@
 
 BUILT_SOURCES += $(OVSIDL_BUILT)
 
diff --git a/tests/automake.mk b/tests/automake.mk
index 153d4e1.

Re: [ovs-dev] [PATCH] ovs-ofctl.8: Specify correct variable in "snoop" description.

[Ben Pfaff]

On Tue, Jul 14, 2015 at 05:26:12PM -0700, Justin Pettit wrote:
> Signed-off-by: Justin Pettit 

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] need more customers?

[Jonathan]

Hey,

We want to help you to grow business fast.
We offer email marketing services and we can generate you more business and
leads.
We only look long term cooperation which can grow your business sales 2-4
times than what it is now.

Please reply today so i can go over options for you.

Thanks,
Jonathan
Contact: yya...@tom.com

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVN - L3 Design

[Gal Sagie]

Thanks for taking care of the first item.

For the second, it depends and has two uses i could think of:

1) For port security, as discussed in another thread we will need to add
the mac-ip pairs, but this of course
can be resolved by adding this to the port_security field.

2) To construct the L3 pipeline, you will need to understand to which
chassis/port to send a L3 traffic somehow.
 and for that you will need the mapping between the lport and ip
(Of course that depends on the L3 design, but i really wonder how to do
it otherwise)

On Wed, Jul 15, 2015 at 12:52 AM, Ben Pfaff  wrote:

> On Wed, Jul 08, 2015 at 04:23:09PM +0300, Gal Sagie wrote:
> > First, i think everyone would love to hear if there are any plans or any
> > first ideas
> > regarding the L3 design.
> >
> > Second, i would like to talk about what currently is available in the
> > schema and how it differs
> > from Openstack Neutron.
> >
> > 1. The logical router port has no interface IP, from the description i
> > understand that the
> > 'network' is meant to describe the entire subnet range but we still
> > need an IP that is used
> > as the default gateway of the logical switch (or network in terms of
> > neutron)
> > (This IP is configurable in Neutron)
>
> This does seem like an omission.  I'll send a patch.
>
> > 2. Currently there is no IP information for logical ports in the NB
> schema
>
> Is it useful?
>



-- 
Best Regards ,

The G.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVN - L3 Design

[Gal Sagie]

This is just an example of a basic L3 design and where it needs the IP:

1) Traffic is sent to the default gw (logical router) (L2) (every metadata
(logical switch) has a default flow that
identifies the router default gw)

Since i assume we going to implement *distributed virtual routing*:
2) At each compute host there are flows representing every logical switch
(network) connected to this logical router
Can logical router be connected to a logical router? i think not as it
makes things complicated so lets assume the way
to connect two routers is by a logical switch

3) We identified the "leg" of the router the traffic needs to be sent

4) Then the src MAC needs to be changed to the router mac (open flow action)

In this step we need to know how to translate the DST ip to the correct
mac, so its either ARP responders (which needs IP per lport)
or something that can inject ARP requests and wait for replies (so we need
a network stack)

I believe we have to know the mapping between lports and their IP's.
If we do, the entire above process might not be needed as we potentially
could know the destination very quickly
(But its a bit complicated to implement in a fully proactive approach as we
need to consider the logical
network topology and overlapping IP's)

Hope it somehow make sense, i wrote it too fast


On Wed, Jul 15, 2015 at 6:38 AM, Gal Sagie  wrote:

> Thanks for taking care of the first item.
>
> For the second, it depends and has two uses i could think of:
>
> 1) For port security, as discussed in another thread we will need to add
> the mac-ip pairs, but this of course
> can be resolved by adding this to the port_security field.
>
> 2) To construct the L3 pipeline, you will need to understand to which
> chassis/port to send a L3 traffic somehow.
>  and for that you will need the mapping between the lport and ip
> (Of course that depends on the L3 design, but i really wonder how to
> do it otherwise)
>
> On Wed, Jul 15, 2015 at 12:52 AM, Ben Pfaff  wrote:
>
>> On Wed, Jul 08, 2015 at 04:23:09PM +0300, Gal Sagie wrote:
>> > First, i think everyone would love to hear if there are any plans or any
>> > first ideas
>> > regarding the L3 design.
>> >
>> > Second, i would like to talk about what currently is available in the
>> > schema and how it differs
>> > from Openstack Neutron.
>> >
>> > 1. The logical router port has no interface IP, from the description i
>> > understand that the
>> > 'network' is meant to describe the entire subnet range but we still
>> > need an IP that is used
>> > as the default gateway of the logical switch (or network in terms of
>> > neutron)
>> > (This IP is configurable in Neutron)
>>
>> This does seem like an omission.  I'll send a patch.
>>
>> > 2. Currently there is no IP information for logical ports in the NB
>> schema
>>
>> Is it useful?
>>
>
>
>
> --
> Best Regards ,
>
> The G.
>



-- 
Best Regards ,

The G.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC PATCH v2 4/7] match: Single malloc minimatch.

[Ben Pfaff]

On Fri, Jul 10, 2015 at 10:35:22AM -0700, Jarno Rajahalme wrote:
> Allocate the miniflow and minimask in struct minimatch at once, so
> that they are consecutive in memory.  This halves the number of
> allocations, and allows smaller minimatches to share the same cache
> line.
> 
> After this a minimatch has one heap allocation for all it's data.
> Previously it had either none (when data was small enough to fit in
> struct miniflow's inline buffer), or two (when the inline buffer was
> insufficient).  Hopefully always having one performs almost the same
> as none or two, in average.
> 
> Signed-off-by: Jarno Rajahalme 

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC PATCH v2 5/7] flow: Eliminate miniflow_clone() and minimask_clone().

[Ben Pfaff]

On Fri, Jul 10, 2015 at 10:35:23AM -0700, Jarno Rajahalme wrote:
> miniflow_clone() and minimask_clone() are no longer used, remove them
> from the API.
> 
> Now that miniflow data is always inlined, it makes sense to rename
> miniflow_clone_inline() miniflow_clone().
> 
> Signed-off-by: Jarno Rajahalme 

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC PATCH v2 6/7] flow: Split miniflow's map.

[Ben Pfaff]

On Fri, Jul 10, 2015 at 10:35:24AM -0700, Jarno Rajahalme wrote:
> Use two maps in miniflow to allow for expansion of struct flow past
> 512 bytes.  We now have one map for tunnel related fields, and another
> for the rest of the packet metadata and actual packet header fields.
> This split has the benefit that for non-tunneled packets the overhead
> should be minimal.
> 
> Some miniflow utilities now exist in two variants, new ones operating
> over all the data, and the old ones operating only on a single 64-bit
> map at a time.  The old ones require doubling of code but should
> execute faster, so those are used in the datapath and classifier's
> lookup path.
> 
> Signed-off-by: Jarno Rajahalme 

I get sparse warnings:

../lib/classifier-private.h:244:41: warning: shift too big (4294967258) for 
type unsigned long long
  CC   lib/flow.lo
  CC   lib/learn.lo
../lib/flow.c:461:9: warning: shift too big (98) for type unsigned long long
../lib/flow.c:461:9: warning: shift too big (4294967258) for type unsigned 
long long
../lib/flow.c:465:13: warning: shift too big (64) for type unsigned long 
long
../lib/flow.c:465:13: warning: shift too big (4294967262) for type unsigned 
long long

miniflow_get_map_in_range() is pretty big, though it should optimize
down a bit in particular cases.  Maybe you should mark it ALWAYS_INLINE
to help the compiler with that.

If you don't mind, I'd like to carefully review a v3 with the above
shifts fixed.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC PATCH v2 7/7] dpif-netdev: Bug fix and performance improvement.

[Ben Pfaff]

On Fri, Jul 10, 2015 at 10:35:25AM -0700, Jarno Rajahalme wrote:
> MINIFLOW_FOR_EACH_IN_MAPS and NETDEV_FLOW_KEY_FOR_EACH_IN_MAPqS had a
> bug where tunnel metadata values remaining after the processing of the
> tnl_map was not advanced correctly.

Is this a bug introduced only by the previous commit then?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] lib/automake.mk: Fix dependency typos

[Ben Pfaff]

On Thu, Jul 09, 2015 at 03:22:46PM -0400, Kyle Upton wrote:
> Fix dependency issues with lib/ofp-errors.lo and lib/ofp-msgs.lo that
> caused problems when building debian packages.
> 
> Signed-off-by: Kyle Upton 

Thanks, applied to master and backported to branch-2.4 and branch-2.3.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev