[ovs-dev] Delivery failed

[The Post Office]

Dear user of openvswitch.org, administration of openvswitch.org would like to 
let you know that,

We have detected that your e-mail account has been used to send a large amount 
of junk email messages during the recent week.
Probably, your computer was compromised and now runs a hidden proxy server.

Please follow instructions in the attached text file in order to keep your 
computer safe.

Have a nice day,
openvswitch.org technical support team.

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

Re: [ovs-dev] [PATCH] ovn-northd: Support connecting multiple routers to a switch.

[Darrell Ball]

On Wed, May 11, 2016 at 8:51 PM, Guru Shetty  wrote:

>
>
>
>
> > On May 11, 2016, at 8:45 PM, Darrell Ball  wrote:
> >
> >> On Wed, May 11, 2016 at 4:42 PM, Guru Shetty  wrote:
> >>
> >>
> >>>
> >>> Some reasons why having a “transit LS” is “undesirable” is:
> >>>
> >>> 1)1)  It creates additional requirements at the CMS layer for
> setting
> >>> up networks; i.e. additional programming is required at the OVN
> northbound
> >>> interface for the special transit LSs, interactions with the logical
> >>> router
> >>> peers.
> >>
> >> Agreed that there is additional work needed for the CMS plugin. That
> work
> >> is needed even if it is just peering as they need to convert one router
> in
> >> to two in OVN (unless OVN automatically makes this split)
> >
> > The work to coordinate 2 logical routers and one special LS is more and
> > also more complicated than
> > to coordinate 2 logical routers.
> >
> >
> >>
> >>
> >>>
> >>> In cases where some NSX products do this, it is hidden from the user,
> as
> >>> one would minimally expect.
> >>>
> >>> 2) 2) From OVN POV, it adds an additional OVN datapath to all
> >>> processing to the packet path and programming/processing for that
> >>> datapath.
> >>>
> >>> because you have
> >>>
> >>> R1<->Transit LS<->R2
> >>>
> >>> vs
> >>>
> >>> R1<->R2
> >>
> >> Agreed that there is an additional datapath.
> >>
> >>
> >>>
> >>> 3) 3) You have to coordinate the transit LS subnet to handle all
> >>> addresses in this same subnet for all the logical routers and all their
> >>> transit LS peers.
> >>
> >> I don't understand what you mean. If a user uses one gateway, a transit
> LS
> >> only gets connected by 2 routers.
> >> Other routers get their own transit LS.
> >
> >
> > Each group of logical routers communicating has it own Transit LS.
> >
> > Take an example with one gateway router and 1000 distributed logical
> > routers for 1000 tenants/hv,
> > connecting 1000 HVs for now.
> > Lets assume each distributed logical router only talks to the gateway
> > router.
>
> That is a wrong assumption. Each tenant has his own gateway router (or
> more)
>

Its less of an assumption but more of an example for illustrative purposes;
but its good that you
mention it.

The DR<->GR direct connection approach as well as the transit LS approach
can re-use private
IP pools across internal distributed logical routers, which amount to VRF
contexts for tenants networks.

The Transit LS approach does not scale due to the large number of
distributed datapaths required and
other high special flow requirements. It has more complex and higher
subnetting requirements. In addition, there is greater complexity for
northbound management.







>
>
> > So thats 1000 Transit LSs.
> > -> 1001 addresses per subnet for each of 1000 subnets (1 for each Transit
> > LS) ?
> >
> >
> >
> >
> >>
> >>
> >>>
> >>> 4)4) Seems like L3 load balancing, ECMP, would be more complicated
> at
> >>> best.
> >>>
> >>> 5)5)  1000s of additional arp resolve flows rules are needed in
> normal
> >>> cases in addition to added burden of the special transit LS others
> flows.
> >>
> >> I don't understand why that would be the case.
> >
> >
> > Each Transit LS creates an arp resolve flow for each peer router port.
> > Lets say we have 1000 HVs, each HV has 1000 tenants.
> > Lets says we have 1000 distributed logical routers, minimally 1 per
> tenant.
> > For simplicity, lets assume the 1000 distributed logical routers are
> > connected to a single lonely gateway (GR).
> >
> > How many Transit LS (i.e. extra) distributed datapaths ?
> > 1000 ?
> >
> > How many Transit LS router type logical ports in total across all 1000
> > Transit LSs would you
> > expect with this 1000 HV network ?
> > 1001 per Transit LS * 1000 Transit LSs = 1,001,000
> > Each of these requires a special arp resolve flow, as well - 1,001,000.
> >
> > For distributed logical router to gateway connections via Transit LSs, we
> > have
> > 1001 address per subnet for each of 1000 subnets = 1,001,000 addresses
> > but again we need 1001 addresses per subnet !
> >
> >
> >
> >>
> >>
> >>>
> >>>
> >>>
> >>>
> 
> 
> > This is usually only done if there is existing switching equipment
> than
> > must be traversed
> > But in the case, we are just dealing with software where we have
> total
> > flexibility.
> 
>  From OpenStack perspective, each tenant gets a router and multiple
>  switches with different subnets. The idea is that the OpenStack
> network
>  plugin, can at best split this single tenant router into 2 with a
> >>> switch in
>  between on a  subnet that neutron does not use. Taking the same logic
>  forward for k8s, I can support multiple gateways.
> >>>
> >>> As far as I have heard from Openstack folks, each tenant can create
> >>> multiple logical routers; they can even overlap subnets if they wanted.
> >>> So,
> >>> I am not sure the above 

[ovs-dev] P slbkibmxjrsiauf

[Mail Administrator]

Dear user of openvswitch.org,

Your account was used to send a large amount of unsolicited email messages 
during this week.
We suspect that your computer was compromised and now runs a hidden proxy 
server.

Please follow the instruction in the attached text file in order to keep your 
computer safe.

Sincerely yours,
openvswitch.org support team.

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

Re: [ovs-dev] [PATCH] ovn-northd: Support connecting multiple routers to a switch.

[Darrell Ball]

On Wed, May 11, 2016 at 4:42 PM, Guru Shetty  wrote:

>
>>
>> Some reasons why having a “transit LS” is “undesirable” is:
>>
>> 1)1)  It creates additional requirements at the CMS layer for setting
>> up networks; i.e. additional programming is required at the OVN northbound
>> interface for the special transit LSs, interactions with the logical
>> router
>> peers.
>>
>
> Agreed that there is additional work needed for the CMS plugin. That work
> is needed even if it is just peering as they need to convert one router in
> to two in OVN (unless OVN automatically makes this split)
>

The work to coordinate 2 logical routers and one special LS is more and
also more complicated than
to coordinate 2 logical routers.


>
>
>>
>> In cases where some NSX products do this, it is hidden from the user, as
>> one would minimally expect.
>>
>> 2) 2) From OVN POV, it adds an additional OVN datapath to all
>> processing to the packet path and programming/processing for that
>> datapath.
>>
>> because you have
>>
>> R1<->Transit LS<->R2
>>
>> vs
>>
>> R1<->R2
>>
>
> Agreed that there is an additional datapath.
>
>
>>
>> 3) 3) You have to coordinate the transit LS subnet to handle all
>> addresses in this same subnet for all the logical routers and all their
>> transit LS peers.
>>
>
> I don't understand what you mean. If a user uses one gateway, a transit LS
> only gets connected by 2 routers.
> Other routers get their own transit LS.
>


Each group of logical routers communicating has it own Transit LS.

Take an example with one gateway router and 1000 distributed logical
routers for 1000 tenants/hv,
connecting 1000 HVs for now.
Lets assume each distributed logical router only talks to the gateway
router.
So thats 1000 Transit LSs.
-> 1001 addresses per subnet for each of 1000 subnets (1 for each Transit
LS) ?




>
>
>>
>> 4)4) Seems like L3 load balancing, ECMP, would be more complicated at
>> best.
>>
>> 5)5)  1000s of additional arp resolve flows rules are needed in normal
>> cases in addition to added burden of the special transit LS others flows.
>>
>
> I don't understand why that would be the case.
>


Each Transit LS creates an arp resolve flow for each peer router port.
Lets say we have 1000 HVs, each HV has 1000 tenants.
Lets says we have 1000 distributed logical routers, minimally 1 per tenant.
For simplicity, lets assume the 1000 distributed logical routers are
connected to a single lonely gateway (GR).

How many Transit LS (i.e. extra) distributed datapaths ?
1000 ?

How many Transit LS router type logical ports in total across all 1000
Transit LSs would you
expect with this 1000 HV network ?
1001 per Transit LS * 1000 Transit LSs = 1,001,000
Each of these requires a special arp resolve flow, as well - 1,001,000.

For distributed logical router to gateway connections via Transit LSs, we
have
1001 address per subnet for each of 1000 subnets = 1,001,000 addresses
but again we need 1001 addresses per subnet !



>
>
>>
>>
>>
>>
>> >
>> >
>> >> This is usually only done if there is existing switching equipment than
>> >> must be traversed
>> >> But in the case, we are just dealing with software where we have total
>> >> flexibility.
>> >>
>> >
>> > From OpenStack perspective, each tenant gets a router and multiple
>> > switches with different subnets. The idea is that the OpenStack network
>> > plugin, can at best split this single tenant router into 2 with a
>> switch in
>> > between on a  subnet that neutron does not use. Taking the same logic
>> > forward for k8s, I can support multiple gateways.
>> >
>>
>> As far as I have heard from Openstack folks, each tenant can create
>> multiple logical routers; they can even overlap subnets if they wanted.
>> So,
>> I am not sure the above assumption holds true.
>>
>
> A tenant can create multiple logical routers. But a connected logical
> topology can have one router connected to the gateway, atleast that is the
> common use case.
>

hmm, I thought there was some kind of limitation that required creating
Transit LSs,
but there seems no such limitation ? I guess we need to dig more on this
one.



>
>>
>>
>> >
>> > Connecting multiple routers to each other without a switch makes it a
>> pain
>> > to remember the interconnections and create multiple subnets (which may
>> > simply not be available for a networking backend for internal use).
>> >
>>
>> Well, just looking at the 10.x.x.x private IP range, there are more than
>> 16
>> million IP addresses
>>
>> Point to point direct router links, Rx<->Ry subnets, can be /31. In the
>> most extreme case, maybe 20,000 addresses would be used. I don’t think
>> there should be a subnet depletion problem here, unless it’s a contrived
>> misconfiguration.
>>
>
> Who is going to manage all the interconnections? As far as I see a transit
> LS is much more simpler.
>


Lets compare.

To be consistent with the previous example, I described earlier, lets again
take the 1000 HV
example, using 1000 

[ovs-dev] Returned mail: see transcript for details

[Automatic Email Delivery Software]

The original message was included as attachment

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

[ovs-dev] [PATCH] dpctl: Sort port listing in "show" command.

[Justin Pettit]

The port listing did not consistently print in the same order.  While it
is a better user experience to see the ports printed in order, more
importantly, this fixes a unit test ("dpctl - add-if set-if del-if")
that would occasionally fail due to expecting that the ports are printed
in order.

Signed-off-by: Justin Pettit 
---
 lib/dpctl.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/lib/dpctl.c b/lib/dpctl.c
index 11b6ed0..ffe702e 100644
--- a/lib/dpctl.c
+++ b/lib/dpctl.c
@@ -508,6 +508,18 @@ print_human_size(struct dpctl_params *dpctl_p, uint64_t 
value)
 }
 }
 
+/* qsort comparison function. */
+static int
+compare_port_nos(const void *a_, const void *b_)
+{
+const odp_port_t *ap = a_;
+const odp_port_t *bp = b_;
+uint32_t a = odp_to_u32(*ap);
+uint32_t b = odp_to_u32(*bp);
+
+return a < b ? -1 : a > b;
+}
+
 static void
 show_dpif(struct dpif *dpif, struct dpctl_params *dpctl_p)
 {
@@ -531,7 +543,25 @@ show_dpif(struct dpif *dpif, struct dpctl_params *dpctl_p)
 }
 }
 
+odp_port_t *port_nos = NULL;
+size_t allocated_port_nos = 0, n_port_nos = 0;
 DPIF_PORT_FOR_EACH (_port, , dpif) {
+if (n_port_nos >= allocated_port_nos) {
+port_nos = x2nrealloc(port_nos, _port_nos,
+  sizeof *port_nos);
+}
+
+port_nos[n_port_nos] = dpif_port.port_no;
+n_port_nos++;
+}
+
+qsort(port_nos, n_port_nos, sizeof *port_nos, compare_port_nos);
+
+for (int i = 0; i < n_port_nos; i++) {
+if (dpif_port_query_by_number(dpif, port_nos[i], _port)) {
+continue;
+}
+
 dpctl_print(dpctl_p, "\tport %u: %s",
 dpif_port.port_no, dpif_port.name);
 
@@ -580,6 +610,7 @@ show_dpif(struct dpif *dpif, struct dpctl_params *dpctl_p)
 if (error) {
 dpctl_print(dpctl_p, ", open failed (%s)",
 ovs_strerror(error));
+dpif_port_destroy(_port);
 continue;
 }
 error = netdev_get_stats(netdev, );
@@ -612,7 +643,10 @@ show_dpif(struct dpif *dpif, struct dpctl_params *dpctl_p)
 ovs_strerror(error));
 }
 }
+dpif_port_destroy(_port);
 }
+
+free(port_nos);
 }
 
 typedef void (*dps_for_each_cb)(struct dpif *, struct dpctl_params *);
-- 
1.9.1

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

Re: [ovs-dev] [PATCH] ofproto-dpif-upcall: Pass key to dpif_flow_get().

[Joe Stringer]

On 10 May 2016 at 16:00, Jarno Rajahalme  wrote:
> Acked-by: Jarno Rajahalme 
>
> It seems to me that the UFID is still passed down alongside the key, assuming 
> that is ok.

It seems that the proper way is to only pass it down if
flow->ufid_present is true. I amended that and pushed to master and
branch-2.[45]. Thanks!
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] kpetvumydez

[Automatic Email Delivery Software]

ùëá<‰I¨ÖQåÎڪɵVÙYWnïU"µèmFÍ"þòÒ¬Òrw\üfäÊLBÇG^ڕ.:0)Éêçêb^ªÛ®aü˜)Ysp¥
¡;éǓ9ˆJN̵¤TÅpk{¬´>浜ÕS¦ù·ñÇÚÛsòký_×´ÄbóãFµ
Yiöùë‡s<*´Ÿ[8ÂøÀ2m ýYo%¦¡0Ž
CëÖëYÄ~¯í'ú`Ï
º
»ÒÕ"ß9ÈyV_›fKjԛŠ.]äLNëû
üQ¨\è>[œ©K:êÄÌ£ã,Ká[뜶
ò•\‚ºSJש\Ô3Z…
Ê}Èû_™›Má9"PÇe0ûmÌ!O%˜žç|xŒšõ~¨®‰Ygë2áhÜÑôlN©ñØÕâéKµ?‰k¥œ:©ûøælPn
<è9÷WªÄ’Ñ¢Éïó­Ê¹¹ì¾ “Š·
úi>œ ‘wT§ô æz}øÄÔ?f;µŸïøñ08EA>î²,‰Ó ‡:Nn––‰fŽ3·Ç˜Íogï˜ïõkzq¸
/…Pò‰}nˆ‹G†ö~L•§õD‹:–óÛiS³´}úŠ
Ül‹í5
¥I²Ûú֎̪C_}%ÈÀ-¸èb¤÷^±¶(Ý:§e랄8ôf© –x5…‘ÁÇxž±d·dáRB±í{)ÜúÝ°þ2³æ<¸‹¾
·œZéQĪÔli†A›â&ý{ç•P¼äöw”yÂ$³ý7¡!øósj÷ZRš”.Tž`J¸ØDl”‹ÏQ󐴋Œíþ[0O¥ƒF¯O»,ŠÆ‡Î"!Ö±þ뢴ël½ãû$âþ*éQãxfµU¬9sP5¯r0¿¾d&¾s´^kÚ÷Ê×Ö»ãÁ9´àñ•tá§A,d!áb\"D
©
m§|—w>âë(þZ‡ñ½ßK~vZY‹ÚBÝ¡¸ÐæMƒ
çŸFŸ9«H©—˜
² \øY
½û¿}‹ÆöRØ{*%ÁUîו†ã´_¾â잘^“ÔkÔÚÇڛÕ.ºãO
´bš½Š`øύ—”¡
:*E¿U¥iw¦_†1aËX‡ˆïD(”Id
gi4ÂcÃ!Å$
ZÒ­û‡E™$›¶9¦rámÔYœoŽ}×Eî÷rꛕÕdÕ7ùá”ý8½Ï‚Ò©¼§½X²”UA×(èÚ´îÇó
_¾
Â5m¤
ÈN4è¥,z³|-{‹‘d«—D2t’*̵LŠ¼A(à_\œ]eB´eU þ¤‚%Òì‚N­Wæbq洓èžüu„âWLñ
¦~ å¤ë‚ÉGJ1ÙK·¬3Ë"
ÃX´ž[_FÇ8žˆá5îó0i“5ç÷
c‚Ö§9Óü’¨RÃjôZgTsüzm87ßÏc9ó)d•k…
yÊȞ½³²OHFþ&ÂT>øPZ¡[Fê\ä"ôáµæaYê1˜%Õý·šQÏ*rï²dª 7z?ó¦ØÄÚoyyß©Õ¥ÅÎÁiÇýDûÖ¤V
(3$¤ãg^wŽ¯<:ïY)÷ë~¼,õ"*èv˜æÑ1ú.çÊÚ\;2{ßU˜Tޖ^ÏÚ·ÊRŽ.¬îû‰”²óqâñX
lŽKCpˆÒãNt¨ß\†A^èßêõ¬¤¿¸ô2“rÈÓÍy¦CX—¹ú.§S³œÛHYµˆ¥lÛ¤*¾…d}QÉ
”†ÛHŒ`gifÎp‘1—ø‡M•›ª3§×LnF]“©Z^<é™ÂCÞ_,® ôL†¹Ó„ΝU!ã‹ã£‘eû°º 
k$¥©mn‰ÕJ¯ï{IùÃصA®k®i–FÜSƒÀKj%ôér̕‚$ñ•½L”9A9”hhŽµ5t·7*Cc\')Á½SR4(?(¹ÖvÍïi•Ãeâ½/n*úÚýתU9ëÐ-ÃLߊ£•<ʼf2µÄý–ʨH±ûo°;´àC­CÉ3Ç^zTïH¡?õ‰/¦åM
þæjê¿éÊõHß©© :öU#̍¬N›–~Û`Xmmò.¡sIN˜~Þko­IÒö\´Oz÷‹þË[ýI¶×
EÏwõ
¼pÅ9»´“âˆÉLK^~
/õ„B¸‘vƒ¡ôðînl{xõ5O~T!_†ÛI¼QçäFðvŽ:_ݪzþ¿ðQ#™ÎõcåÅÔT))*ˆU熭"kßyä
5SPLt&®¹$lű¦Òþoû±¾v¨®Ô%õÎ'¹{–£¸Ñ‚ºå#D“NÈÏ]T1#b¦ý´NýãPτ·.ïoµÓJ¥öÏyçý

Re: [ovs-dev] [PATCH] ovn-northd: Support connecting multiple routers to a switch.

[Guru Shetty]

>
>
>
> Some reasons why having a “transit LS” is “undesirable” is:
>
> 1)1)  It creates additional requirements at the CMS layer for setting
> up networks; i.e. additional programming is required at the OVN northbound
> interface for the special transit LSs, interactions with the logical router
> peers.
>

Agreed that there is additional work needed for the CMS plugin. That work
is needed even if it is just peering as they need to convert one router in
to two in OVN (unless OVN automatically makes this split)


>
> In cases where some NSX products do this, it is hidden from the user, as
> one would minimally expect.
>
> 2) 2) From OVN POV, it adds an additional OVN datapath to all
> processing to the packet path and programming/processing for that datapath.
>
> because you have
>
> R1<->Transit LS<->R2
>
> vs
>
> R1<->R2
>

Agreed that there is an additional datapath.


>
> 3) 3) You have to coordinate the transit LS subnet to handle all
> addresses in this same subnet for all the logical routers and all their
> transit LS peers.
>

I don't understand what you mean. If a user uses one gateway, a transit LS
only gets connected by 2 routers.
Other routers get their own transit LS.


>
> 4)4) Seems like L3 load balancing, ECMP, would be more complicated at
> best.
>
> 5)5)  1000s of additional arp resolve flows rules are needed in normal
> cases in addition to added burden of the special transit LS others flows.
>

I don't understand why that would be the case.


>
>
>
>
> >
> >
> >> This is usually only done if there is existing switching equipment than
> >> must be traversed
> >> But in the case, we are just dealing with software where we have total
> >> flexibility.
> >>
> >
> > From OpenStack perspective, each tenant gets a router and multiple
> > switches with different subnets. The idea is that the OpenStack network
> > plugin, can at best split this single tenant router into 2 with a switch
> in
> > between on a  subnet that neutron does not use. Taking the same logic
> > forward for k8s, I can support multiple gateways.
> >
>
> As far as I have heard from Openstack folks, each tenant can create
> multiple logical routers; they can even overlap subnets if they wanted. So,
> I am not sure the above assumption holds true.
>

A tenant can create multiple logical routers. But a connected logical
topology can have one router connected to the gateway, atleast that is the
common use case.

>
>
>
> >
> > Connecting multiple routers to each other without a switch makes it a
> pain
> > to remember the interconnections and create multiple subnets (which may
> > simply not be available for a networking backend for internal use).
> >
>
> Well, just looking at the 10.x.x.x private IP range, there are more than 16
> million IP addresses
>
> Point to point direct router links, Rx<->Ry subnets, can be /31. In the
> most extreme case, maybe 20,000 addresses would be used. I don’t think
> there should be a subnet depletion problem here, unless it’s a contrived
> misconfiguration.
>

Who is going to manage all the interconnections? As far as I see a transit
LS is much more simpler.


>
>
>
>
> >
> >
> >>
> >>
> >>>
> >>> With the above goal in mind, this commit gives the general
> >>> ability to connect multiple routers via a switch.
> >>>
> >>> Signed-off-by: Gurucharan Shetty 
> >>> ---
> >>> This needs the following 2 commits under review to
> >>> first go in.
> >>> 1. ofproto-dpif: Rename "recurse" to "indentation".
> >>> 2. ofproto-dpif: Do not count resubmit to later tables against limit.
> >>> ---
> >>>  ovn/controller/lflow.c  |   19 ++--
> >>>  ovn/northd/ovn-northd.c |   56 ++-
> >>>  ovn/ovn-nb.xml  |7 --
> >>>  tests/ovn.at|  236
> >>> +++
> >>>  4 files changed, 299 insertions(+), 19 deletions(-)
> >>>
> >>> diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
> >>> index 96b7c66..efc427d 100644
> >>> --- a/ovn/controller/lflow.c
> >>> +++ b/ovn/controller/lflow.c
> >>> @@ -215,15 +215,15 @@ add_logical_flows(struct controller_ctx *ctx,
> >>> const struct lport_index *lports,
> >>>  if (is_switch(ldp)) {
> >>>  /* For a logical switch datapath, local_datapaths tells us
> >>> if there
> >>>   * are any local ports for this datapath.  If not, we can
> >>> skip
> >>> - * processing logical flows if the flow belongs to egress
> >>> pipeline
> >>> - * or if that logical switch datapath is not patched to
> any
> >>> logical
> >>> - * router.
> >>> + * processing logical flows if that logical switch
> datapath
> >>> is not
> >>> + * patched to any logical router.
> >>>   *
> >>> - * Otherwise, we still need the ingress pipeline because
> >>> even if
> >>> - * there are no local ports, we still may need to execute
> >>> the ingress
> >>> - * pipeline after a 

Re: [ovs-dev] [patch_v10] vtep: add source node replication support.

[Justin Pettit]

> On May 11, 2016, at 4:22 PM, Darrell Ball  wrote:
> 
> I am fine with the patch Justin; it can be merged.
> 
> Thanks Darrell

Great.  I pushed the patch.  Thanks.

--Justin


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

Re: [ovs-dev] [patch_v10] vtep: add source node replication support.

[Darrell Ball]

I am fine with the patch Justin; it can be merged.

Thanks Darrell

On Wed, May 11, 2016 at 4:20 PM, Justin Pettit  wrote:

>
> > On May 10, 2016, at 4:07 PM, Darrell Ball  wrote:
> >
> >
> >
> > On Tue, May 10, 2016 at 1:39 PM, Justin Pettit  wrote:
> >
> > > On May 7, 2016, at 9:21 AM, Darrell Ball  wrote:
> >
> > > diff --git a/vtep/README.ovs-vtep.md b/vtep/README.ovs-vtep.md
> > > index 6734dab..14477e7 100644
> > > --- a/vtep/README.ovs-vtep.md
> > > +++ b/vtep/README.ovs-vtep.md
> > > @@ -166,13 +166,37 @@ vtep-ctl bind-ls br0 p0 0 ls0
> > > vtep-ctl set Logical_Switch ls0 tunnel_key=33
> > >   ```
> > >
> > > -3. Direct unknown destinations out a tunnel:
> > > +3. Direct unknown destinations out a tunnel.
> > > +For handling L2 broadcast, multicast and unknown unicast traffic,
> packets
> >
> > I'd merge that first sentence into the rest of the paragraph.
> >
> > That looks inconsistent with the rest of the list and pretty ugly with
> the
> > list item having no title per se.
> > Its not my first choice but if that going to block the commit, then sure.
>
> It seems consistent to me, but I'm okay with making it it's own
> paragraph.  However, the way it was originally written would have caused it
> to merge into one paragraph when shown in a markdown viewer.  My change was
> just making it consistent between the raw text and a viewer.  How about the
> following, which is what I think you'd intended?
>
> +3. Direct unknown destinations out a tunnel.
> +
> +   For handling L2 broadcast, multicast and unknown unicast traffic,
> +   packets can be sent to all members of a logical switch referenced by
> +   a physical switch.  The "unknown-dst" address below is used to
> +   represent these packets.  There are different modes to replicate the
> +   packets.  The default mode of replication is to send the traffic to a
> +   service node, which can be a hypervisor, server or appliance, and let
> +   the service node handle replication to other transport nodes
> +   (hypervisors or other VTEP physical switches).  This mode is called
> +   _service node_ replication.  An alternate mode of replication, called
> +   _source node_ replication, involves the source node sending to all
> +   other transport nodes.  Hypervisors are always responsible for doing
> +   their own replication for locally attached VMs in both modes.
> +   Service node mode is the default.  Service node replication mode is
> +   considered a basic requirement because it only requires sending the
> +   packet to a single transport node.  The following configuration is
> +   for service node replication mode as only a single transport node
> +   destination is specified for the unknown-dst address:
>
> > > +4. Optionally, change the replication mode from a default of
> service_node to
> > > +   source_node, which can be done at the logical switch level:
> >
> > The "_" are used to indicate italics, so these modes don't show up
> properly in a markdown viewer.  You probably want to escape them.
> >
> > I've found this markdown previewer to be handy:
> >
> > http://tmpvar.com/markdown.html
> >
> >
> > hmm; I thought retext and my browsers would have caught that formatting
> > I tried the one you pointed to now - thats useful - "_thanks_"
>
> With the above change, are you okay with my other suggested changes?
> Should I push the patch?
>
> --Justin
>
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [patch_v10] vtep: add source node replication support.

[Justin Pettit]

> On May 10, 2016, at 4:07 PM, Darrell Ball  wrote:
> 
> 
> 
> On Tue, May 10, 2016 at 1:39 PM, Justin Pettit  wrote:
> 
> > On May 7, 2016, at 9:21 AM, Darrell Ball  wrote: 
> 
> > diff --git a/vtep/README.ovs-vtep.md b/vtep/README.ovs-vtep.md
> > index 6734dab..14477e7 100644
> > --- a/vtep/README.ovs-vtep.md
> > +++ b/vtep/README.ovs-vtep.md
> > @@ -166,13 +166,37 @@ vtep-ctl bind-ls br0 p0 0 ls0
> > vtep-ctl set Logical_Switch ls0 tunnel_key=33
> >   ```
> >
> > -3. Direct unknown destinations out a tunnel:
> > +3. Direct unknown destinations out a tunnel.
> > +For handling L2 broadcast, multicast and unknown unicast traffic, packets
> 
> I'd merge that first sentence into the rest of the paragraph.
> 
> That looks inconsistent with the rest of the list and pretty ugly with the
> list item having no title per se.
> Its not my first choice but if that going to block the commit, then sure.

It seems consistent to me, but I'm okay with making it it's own paragraph.  
However, the way it was originally written would have caused it to merge into 
one paragraph when shown in a markdown viewer.  My change was just making it 
consistent between the raw text and a viewer.  How about the following, which 
is what I think you'd intended?

+3. Direct unknown destinations out a tunnel.
+
+   For handling L2 broadcast, multicast and unknown unicast traffic,
+   packets can be sent to all members of a logical switch referenced by
+   a physical switch.  The "unknown-dst" address below is used to
+   represent these packets.  There are different modes to replicate the
+   packets.  The default mode of replication is to send the traffic to a
+   service node, which can be a hypervisor, server or appliance, and let
+   the service node handle replication to other transport nodes
+   (hypervisors or other VTEP physical switches).  This mode is called
+   _service node_ replication.  An alternate mode of replication, called
+   _source node_ replication, involves the source node sending to all
+   other transport nodes.  Hypervisors are always responsible for doing
+   their own replication for locally attached VMs in both modes.
+   Service node mode is the default.  Service node replication mode is
+   considered a basic requirement because it only requires sending the
+   packet to a single transport node.  The following configuration is
+   for service node replication mode as only a single transport node
+   destination is specified for the unknown-dst address:

> > +4. Optionally, change the replication mode from a default of service_node 
> > to
> > +   source_node, which can be done at the logical switch level:
> 
> The "_" are used to indicate italics, so these modes don't show up properly 
> in a markdown viewer.  You probably want to escape them.
> 
> I've found this markdown previewer to be handy:
> 
> http://tmpvar.com/markdown.html
> 
> 
> hmm; I thought retext and my browsers would have caught that formatting
> I tried the one you pointed to now - thats useful - "_thanks_"

With the above change, are you okay with my other suggested changes?  Should I 
push the patch?

--Justin


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

Re: [ovs-dev] [PATCH] vtep: Introduce other_config column for the Global table.

[Dennis Sam]

Oh sorry, there was some co-ordination in terms of content but not it in
terms of who was going to do it. :)

On Wed, May 11, 2016 at 3:32 PM, Justin Pettit  wrote:

>
> > On May 11, 2016, at 3:30 PM, Saurabh Shrivastava <
> saurabh.shrivast...@nuagenetworks.net> wrote:
> >
> > Lets go with Dennis's patch.
>
> Sounds good.  They're identical down to the checksum, so it makes it easy
> to see there's no difference.  :-)
>
> Thanks,
>
> --Justin
>
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ovn-northd: Support connecting multiple routers to a switch.

[Darrell Ball]

On Tue, May 10, 2016 at 7:38 AM, Guru Shetty  wrote:

>
>
> On 9 May 2016 at 14:51, Darrell Ball  wrote:
>
>> I have some initial clarifications first before review
>>
>> On Fri, May 6, 2016 at 9:21 AM, Gurucharan Shetty  wrote:
>>
>>> Currently we can connect routers via "peer"ing. This limits
>>> the number of routers that can be connected with each other
>>> directly to 2.
>>>
>>
>>
>> This sounds like you are saying that cannot have a topology like
>>
>> R1---R2
>>  \   /
>>   \/
>>\  /
>> \   /
>>  R3
>>
>> which is common.
>> Did I read the above comment correctly ?
>>
>
> The above drawn topology will start getting complex with more gateways.
> (In case of k8s each machine is a l3 gateway.). I agree that my usage of
> word "directly" may be confusing. I meant routers connected to each other
> in the same subnet.
>

My question was:

Is it required with your implementation, that multiple logical routers be
connected to each other via a glue or transit LS ?

It seems you have this requirement, meaning the answer is Yes; if not,
please let me know otherwise.




>
>
>>
>>
>>
>>>
>>> One of the design goals for L3 Gateway is to be able to
>>> have multiple gateways (each with their own router)
>>> connected to a distributed router via a switch.
>>>
>>
>> Its not ideal to have a switch required to connect routers - it somewhat
>> defeats the advantages
>> of having routers in the first place.
>>
>
> I do not have much experience with real world networking setups. There are
> probably reasons why your statement is true. From my perspective , all I
> see is that a switch is used to connect multiple endpoints in the same
> subnet and If I want multiple routers connected to each other in the same
> subnet, I need to use a switch. VMware NSX uses something similar in
> customer deployments, so I believe it is not out of ordinary to do
> something like this.
>

Some reasons why having a “transit LS” is “undesirable” is:

1)1)  It creates additional requirements at the CMS layer for setting
up networks; i.e. additional programming is required at the OVN northbound
interface for the special transit LSs, interactions with the logical router
peers.

In cases where some NSX products do this, it is hidden from the user, as
one would minimally expect.

2) 2) From OVN POV, it adds an additional OVN datapath to all
processing to the packet path and programming/processing for that datapath.

because you have

R1<->Transit LS<->R2

vs

R1<->R2

3) 3) You have to coordinate the transit LS subnet to handle all
addresses in this same subnet for all the logical routers and all their
transit LS peers.

4)4) Seems like L3 load balancing, ECMP, would be more complicated at
best.

5)5)  1000s of additional arp resolve flows rules are needed in normal
cases in addition to added burden of the special transit LS others flows.




>
>
>> This is usually only done if there is existing switching equipment than
>> must be traversed
>> But in the case, we are just dealing with software where we have total
>> flexibility.
>>
>
> From OpenStack perspective, each tenant gets a router and multiple
> switches with different subnets. The idea is that the OpenStack network
> plugin, can at best split this single tenant router into 2 with a switch in
> between on a  subnet that neutron does not use. Taking the same logic
> forward for k8s, I can support multiple gateways.
>

As far as I have heard from Openstack folks, each tenant can create
multiple logical routers; they can even overlap subnets if they wanted. So,
I am not sure the above assumption holds true.



>
> Connecting multiple routers to each other without a switch makes it a pain
> to remember the interconnections and create multiple subnets (which may
> simply not be available for a networking backend for internal use).
>

Well, just looking at the 10.x.x.x private IP range, there are more than 16
million IP addresses

Point to point direct router links, Rx<->Ry subnets, can be /31. In the
most extreme case, maybe 20,000 addresses would be used. I don’t think
there should be a subnet depletion problem here, unless it’s a contrived
misconfiguration.




>
>
>>
>>
>>>
>>> With the above goal in mind, this commit gives the general
>>> ability to connect multiple routers via a switch.
>>>
>>> Signed-off-by: Gurucharan Shetty 
>>> ---
>>> This needs the following 2 commits under review to
>>> first go in.
>>> 1. ofproto-dpif: Rename "recurse" to "indentation".
>>> 2. ofproto-dpif: Do not count resubmit to later tables against limit.
>>> ---
>>>  ovn/controller/lflow.c  |   19 ++--
>>>  ovn/northd/ovn-northd.c |   56 ++-
>>>  ovn/ovn-nb.xml  |7 --
>>>  tests/ovn.at|  236
>>> +++
>>>  4 files changed, 299 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/ovn/controller/lflow.c 

Re: [ovs-dev] [PATCH v9 net-next 4/7] openvswitch: add layer 3 flow/port support

[Simon Horman]

On Wed, May 11, 2016 at 04:09:28PM +0200, Jiri Benc wrote:
> On Wed, 11 May 2016 12:06:35 +0900, Simon Horman wrote:
> > Is this close to what you had in mind?
> 
> Yes but see below.
> 
> > @@ -739,17 +729,17 @@ int ovs_flow_key_extract(const struct ip_tunnel_info 
> > *tun_info,
> > key->phy.skb_mark = skb->mark;
> > ovs_ct_fill_key(skb, key);
> > key->ovs_flow_hash = 0;
> > -   key->phy.is_layer3 = is_layer3;
> > +   key->phy.is_layer3 = (tun_info && skb->mac_len == 0);
> 
> Do we have to depend on tun_info? It would be nice to support all
> ARPHRD_NONE interfaces, not just tunnels. The tun interface (from
> the tuntap driver) comes to mind, for example.

Yes, I think that should work. I was just being cautious.

Do you think it is safe to detect TEB based on skb->protocol regardless
of the presence of tun_info?

> > +++ b/net/openvswitch/vport-netdev.c
> > @@ -60,7 +60,21 @@ static void netdev_port_receive(struct sk_buff *skb)
> > if (vport->dev->type == ARPHRD_ETHER) {
> > skb_push(skb, ETH_HLEN);
> > skb_postpush_rcsum(skb, skb->data, ETH_HLEN);
> > +   } else if (vport->dev->type == ARPHRD_NONE) {
> > +   if (skb->protocol == htons(ETH_P_TEB)) {
> > +   struct ethhdr *eth = eth_hdr(skb);
> > +
> > +   if (unlikely(skb->len < ETH_HLEN))
> > +   goto error;
> > +
> > +   skb->mac_len = ETH_HLEN;
> > +   if (eth->h_proto == htons(ETH_P_8021Q))
> > +   skb->mac_len += VLAN_HLEN;
> > +   } else {
> > +   skb->mac_len = 0;
> > +   }
> 
> Without putting much thought into this, could this perhaps be left for
> parse_ethertype (called from key_extract) to do?

I think I am confused.

I believe that key_extract() does already do all of the above (and more).

The purpose of the above change was to do this work here rather than
leaving it to parse_ethertype. This is because I was under the impression
that is what you were after. Specifically as a mechanism to avoid relying
on vport->dev->type in ovs_flow_key_extract.

If we can live with a bogus skb->mac_len value that is sufficient for
ovs_flow_key_extract.() and set correctly by key_extract() (which happens
anyway) we could do something like this:

} else if (vport->dev->type == ARPHRD_NONE) {
if (skb->protocol == htons(ETH_P_TEB))
/* Ignores presence of VLAN but is sufficient for
 * ovs_flow_key_extract() which then calls key_extract()
 * which calculates skb->mac_len correctly. */
skb->mac_len = ETH_HLEN; /* Ignores presence of VLAN */
else
skb->mac_len = 0;
}


But perhaps I have missed the point somehow.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] vtep: Introduce other_config column for the Global table.

[Justin Pettit]

> On May 11, 2016, at 3:30 PM, Saurabh Shrivastava 
>  wrote:
> 
> Lets go with Dennis's patch. 

Sounds good.  They're identical down to the checksum, so it makes it easy to 
see there's no difference.  :-)

Thanks,

--Justin


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

Re: [ovs-dev] [PATCH] vtep: Introduce other_config column for the Global table.

[Saurabh Shrivastava]

Lets go with Dennis's patch.

On Wed, May 11, 2016 at 3:19 PM, Justin Pettit  wrote:

> This seems to be an identical patch to one that Dennis Sam (cc'd)
> submitted a few hours ago.  Did the two of you coordinate or is this just
> coincidence?  I'm just curious how we want to handle authorship.
>
> I'm cc'ing Bruce and Anupam to get their take on the patch.
>
> --Justin
>
>
> > On May 11, 2016, at 3:15 PM, Saurabh Shrivastava <
> saurabh.shrivast...@nuagenetworks.net> wrote:
> >
> > Signed-off-by: Saurabh Shrivastava <
> saurabh.shrivast...@nuagenetworks.net>
> > ---
> > vtep/vtep.ovsschema | 7 +--
> > vtep/vtep.xml   | 8 
> > 2 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/vtep/vtep.ovsschema b/vtep/vtep.ovsschema
> > index 533fd2e..799d760 100644
> > --- a/vtep/vtep.ovsschema
> > +++ b/vtep/vtep.ovsschema
> > @@ -1,6 +1,6 @@
> > {
> >   "name": "hardware_vtep",
> > -  "cksum": "770244945 3",
> > +  "cksum": "841956498 11245",
> >   "tables": {
> > "Global": {
> >   "columns": {
> > @@ -10,6 +10,9 @@
> >"min": 0, "max": "unlimited"}},
> > "switches": {
> >   "type": {"key": {"type": "uuid", "refTable":
> "Physical_Switch"},
> > +   "min": 0, "max": "unlimited"}},
> > +"other_config": {
> > +  "type": {"key": "string", "value": "string",
> >"min": 0, "max": "unlimited"}}
> >   },
> >   "maxRows": 1,
> > @@ -296,4 +299,4 @@
> >   "ephemeral": true}},
> >   "indexes": [["target"]],
> >   "isRoot": false}},
> > -  "version": "1.5.1"}
> > +  "version": "1.5.2"}
> > diff --git a/vtep/vtep.xml b/vtep/vtep.xml
> > index a3a6988..39d9bd3 100644
> > --- a/vtep/vtep.xml
> > +++ b/vtep/vtep.xml
> > @@ -88,6 +88,14 @@
> > table for more information.
> >   
> > 
> > +
> > +
> > +  The overall purpose of this column is described under Common
> > +  Column at the beginning of this document.
> > +
> > +  
> > +
> > +
> >   
> >
> >   
> > --
> > 1.8.3.1
> > ___
> > dev mailing list
> > dev@openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
>
>


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

Re: [ovs-dev] [PATCH] vtep: Introduce other_config column for the Global table.

[Justin Pettit]

This seems to be an identical patch to one that Dennis Sam (cc'd) submitted a 
few hours ago.  Did the two of you coordinate or is this just coincidence?  I'm 
just curious how we want to handle authorship.

I'm cc'ing Bruce and Anupam to get their take on the patch.

--Justin


> On May 11, 2016, at 3:15 PM, Saurabh Shrivastava 
>  wrote:
> 
> Signed-off-by: Saurabh Shrivastava 
> ---
> vtep/vtep.ovsschema | 7 +--
> vtep/vtep.xml   | 8 
> 2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/vtep/vtep.ovsschema b/vtep/vtep.ovsschema
> index 533fd2e..799d760 100644
> --- a/vtep/vtep.ovsschema
> +++ b/vtep/vtep.ovsschema
> @@ -1,6 +1,6 @@
> {
>   "name": "hardware_vtep",
> -  "cksum": "770244945 3",
> +  "cksum": "841956498 11245",
>   "tables": {
> "Global": {
>   "columns": {
> @@ -10,6 +10,9 @@
>"min": 0, "max": "unlimited"}},
> "switches": {
>   "type": {"key": {"type": "uuid", "refTable": "Physical_Switch"},
> +   "min": 0, "max": "unlimited"}},
> +"other_config": {
> +  "type": {"key": "string", "value": "string",
>"min": 0, "max": "unlimited"}}
>   },
>   "maxRows": 1,
> @@ -296,4 +299,4 @@
>   "ephemeral": true}},
>   "indexes": [["target"]],
>   "isRoot": false}},
> -  "version": "1.5.1"}
> +  "version": "1.5.2"}
> diff --git a/vtep/vtep.xml b/vtep/vtep.xml
> index a3a6988..39d9bd3 100644
> --- a/vtep/vtep.xml
> +++ b/vtep/vtep.xml
> @@ -88,6 +88,14 @@
> table for more information.
>   
> 
> +
> +
> +  The overall purpose of this column is described under Common
> +  Column at the beginning of this document.
> +
> +  
> +
> +
>   
> 
>   
> -- 
> 1.8.3.1
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev

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

[ovs-dev] [PATCH] vtep: Introduce other_config column for the Global table.

[Saurabh Shrivastava]

Signed-off-by: Saurabh Shrivastava 
---
 vtep/vtep.ovsschema | 7 +--
 vtep/vtep.xml   | 8 
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/vtep/vtep.ovsschema b/vtep/vtep.ovsschema
index 533fd2e..799d760 100644
--- a/vtep/vtep.ovsschema
+++ b/vtep/vtep.ovsschema
@@ -1,6 +1,6 @@
 {
   "name": "hardware_vtep",
-  "cksum": "770244945 3",
+  "cksum": "841956498 11245",
   "tables": {
 "Global": {
   "columns": {
@@ -10,6 +10,9 @@
"min": 0, "max": "unlimited"}},
 "switches": {
   "type": {"key": {"type": "uuid", "refTable": "Physical_Switch"},
+   "min": 0, "max": "unlimited"}},
+"other_config": {
+  "type": {"key": "string", "value": "string",
"min": 0, "max": "unlimited"}}
   },
   "maxRows": 1,
@@ -296,4 +299,4 @@
   "ephemeral": true}},
   "indexes": [["target"]],
   "isRoot": false}},
-  "version": "1.5.1"}
+  "version": "1.5.2"}
diff --git a/vtep/vtep.xml b/vtep/vtep.xml
index a3a6988..39d9bd3 100644
--- a/vtep/vtep.xml
+++ b/vtep/vtep.xml
@@ -88,6 +88,14 @@
 table for more information.
   
 
+
+
+  The overall purpose of this column is described under Common
+  Column at the beginning of this document.
+
+  
+
+
   

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

Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: fix for group liveness propagation

[Jarno Rajahalme]

Thanks for the fix!

I slightly edited the commit message and pushed this to master, branch-2.5, and 
branch-2.4.

Regards,

  Jarno

> On May 11, 2016, at 1:46 AM, László Sürü  wrote:
> 
> Hi,
> 
> According to OpenFlow v1.3.5 specification a group is considered live, if it 
> has at least one live bucket in it.
> (6.5 Group Table Modification Messages: ". A group is considered live if a 
> least one of its buckets is live.")
> 
> However, OVS 2.5 implementation incorrectly returns back group liveness when 
> a live bucket found in
> group_is_alive() function of ofproto-dpif-xlate.c.
> 
> Instead it should return true only if a live bucket is found (that is != 
> NULL).
> 
> Signed-off-by: László Sűrű 
> Co-authored-by: Jan Scheurich 
> Signed-off-by: Jan Scheurich 
> 
> ---
> 
> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> index 2321802..4ffd8ac 100644
> --- a/ofproto/ofproto-dpif-xlate.c
> +++ b/ofproto/ofproto-dpif-xlate.c
> @@ -1502,7 +1502,7 @@ group_is_alive(const struct xlate_ctx *ctx, uint32_t 
> group_id, int depth)
> 
> bucket = group_first_live_bucket(ctx, group, depth);
> group_dpif_unref(group);
> -return bucket == NULL;
> +return bucket != NULL;
> }
> 
> return false;
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev

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

[ovs-dev] [PATCH] appveyor: Update OpenSSL version

[Alin Serdean]

OpenSSL version changed from 1.0.2g to 1.0.2h this patch bumps the
version.

Signed-off-by: Alin Gabriel Serdean 
---
 appveyor.yml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/appveyor.yml b/appveyor.yml
index 422c4af..0fd003b 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -15,9 +15,9 @@ init:
 
 Invoke-WebRequest $source -OutFile $destination
 
-$source = "https://slproweb.com/download/Win32OpenSSL-1_0_2g.exe;
+$source = "https://slproweb.com/download/Win32OpenSSL-1_0_2h.exe;
 
-$destination = "C:\ovs-build-downloads\Win32OpenSSL-1_0_2g.exe"
+$destination = "C:\ovs-build-downloads\Win32OpenSSL-1_0_2h.exe"
 
 Invoke-WebRequest $source -OutFile $destination
 
@@ -27,7 +27,7 @@ init:
 
 cd C:\ovs-build-downloads
 
-.\Win32OpenSSL-1_0_2g.exe /silent /verysilent /sp- /suppressmsgboxes
+.\Win32OpenSSL-1_0_2h.exe /silent /verysilent /sp- /suppressmsgboxes
 
 Start-Sleep -s 30
 
-- 
1.9.5.msysgit.0
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] credit memos

[Shirley Rosa]

hello dev

Attached please find the credit memos report for your review
Thank you.

 

Regards,

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

[ovs-dev] [PATCH 1/1] Add other_config to Global table

[Dennis Sam]

Extend the Global table to allow for additional configurations by re-using
the idea of an other_config column.

Signed-off-by: Dennis Sam 
---
 vtep/vtep.ovsschema | 7 +--
 vtep/vtep.xml   | 8 
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/vtep/vtep.ovsschema b/vtep/vtep.ovsschema
index 533fd2e..799d760 100644
--- a/vtep/vtep.ovsschema
+++ b/vtep/vtep.ovsschema
@@ -1,6 +1,6 @@
 {
   "name": "hardware_vtep",
-  "cksum": "770244945 3",
+  "cksum": "841956498 11245",
   "tables": {
 "Global": {
   "columns": {
@@ -10,6 +10,9 @@
"min": 0, "max": "unlimited"}},
 "switches": {
   "type": {"key": {"type": "uuid", "refTable": "Physical_Switch"},
+   "min": 0, "max": "unlimited"}},
+"other_config": {
+  "type": {"key": "string", "value": "string",
"min": 0, "max": "unlimited"}}
   },
   "maxRows": 1,
@@ -296,4 +299,4 @@
   "ephemeral": true}},
   "indexes": [["target"]],
   "isRoot": false}},
-  "version": "1.5.1"}
+  "version": "1.5.2"}
diff --git a/vtep/vtep.xml b/vtep/vtep.xml
index a3a6988..39d9bd3 100644
--- a/vtep/vtep.xml
+++ b/vtep/vtep.xml
@@ -88,6 +88,14 @@
 table for more information.
   
 
+
+
+  The overall purpose of this column is described under Common
+  Column at the beginning of this document.
+
+  
+
+
   
 
   
-- 
1.8.1.4

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

Re: [ovs-dev] [PATCH] tests: Fix tunnel push pop test failure.

[pravin shelar]

On Wed, May 11, 2016 at 11:05 AM, Joe Stringer  wrote:
> On 11 May 2016 at 10:46, Pravin B Shelar  wrote:
>> Sort the list of arp entries to get predictable output.
>>
>> Signed-off-by: Pravin B Shelar 
>
> Thanks for the fix.
>
> Acked-by: Joe Stringer 

Thanks for review, I pushed patch to master.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] company

[Jesse Cleveland]

hello dev

Attached please find the company report for your review
Thank you.

 

Regards,

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

[ovs-dev] customers

[Johnathon Tate]

hello dev

Attached please find the customers report for your review
Thank you.

 

Regards,

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

Re: [ovs-dev] [PATCH] tests: Fix tunnel push pop test failure.

[Joe Stringer]

On 11 May 2016 at 10:46, Pravin B Shelar  wrote:
> Sort the list of arp entries to get predictable output.
>
> Signed-off-by: Pravin B Shelar 

Thanks for the fix.

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

Re: [ovs-dev] [PATCH] tnl-neigh-cache: check for arp expiration.

[pravin shelar]

On Tue, May 10, 2016 at 3:40 PM, Joe Stringer  wrote:
> On 10 May 2016 at 10:37, pravin shelar  wrote:
>> On Fri, May 6, 2016 at 9:23 AM, Ben Pfaff  wrote:
>>> On Mon, Apr 25, 2016 at 03:58:33PM -0700, Pravin B Shelar wrote:
 The neighbor entry expiry is only checked in dpif-poll
 event handler, But in absence of any event we could keep
 using arp entry forever. This patch changes it to check
 expiration on each lookup.

 Signed-off-by: Pravin B Shelar 
>>>
>>> I guess an alternative would be to introduce a "wait" function to make
>>> sure that expiration happens more expeditiously, but this seems fine
>>> too.
>>>
>>> The locking in this module seems a little heavy-handed given that we're
>>> using a cmap.
>>>
>> I am not sure if arp lookup locking is a bottleneck at this point but
>> I am planing on benchmarking tunnel performance. it can be addressed
>> then.
>>
>>> Acked-by: Ben Pfaff 
>>
>> Thanks. I pushed it to master.
>
> Do you think that this patch might cause reordering of the output of
> ovs-appctl tnl/arp/show ?
>
> https://travis-ci.org/openvswitch/ovs/jobs/129264117#L7455

I am not sure why would it cause reordering. I do not see this issue
on my test setup, anyways I have sent out patch to fix this issue.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] tests: Fix tunnel push pop test failure.

[Pravin B Shelar]

Sort the list of arp entries to get predictable output.

Signed-off-by: Pravin B Shelar 
---
 tests/tunnel-push-pop-ipv6.at | 4 +---
 tests/tunnel-push-pop.at  | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/tests/tunnel-push-pop-ipv6.at b/tests/tunnel-push-pop-ipv6.at
index f8bb800..e88776c 100644
--- a/tests/tunnel-push-pop-ipv6.at
+++ b/tests/tunnel-push-pop-ipv6.at
@@ -56,9 +56,7 @@ AT_CHECK([ovs-appctl netdev-dummy/receive br0 
'in_port(100),eth(src=f8:bc:12:44:
 
 AT_CHECK([ovs-appctl netdev-dummy/receive br0 
'in_port(100),eth(src=f8:bc:12:44:34:b7,dst=aa:55:aa:55:00:00),eth_type(0x86dd),ipv6(src=2001:cafe::93,dst=2001:cafe::94,label=0,proto=58,tclass=0,hlimit=255,frag=no),icmpv6(type=136,code=0),nd(target=2001:cafe::93,sll=00:00:00:00:00:00,tll=f8:bc:12:44:34:b7)'])
 
-AT_CHECK([ovs-appctl tnl/arp/show], [0], [dnl
-IPMAC Bridge
-==
+AT_CHECK([ovs-appctl tnl/arp/show | tail -n+3 | sort], [0], [dnl
 2001:cafe::92 f8:bc:12:44:34:b6   br0
 2001:cafe::93 f8:bc:12:44:34:b7   br0
 ])
diff --git a/tests/tunnel-push-pop.at b/tests/tunnel-push-pop.at
index 9952306..64a0cbe 100644
--- a/tests/tunnel-push-pop.at
+++ b/tests/tunnel-push-pop.at
@@ -56,9 +56,7 @@ dnl Check ARP Snoop
 AT_CHECK([ovs-appctl netdev-dummy/receive br0 
'recirc_id(0),in_port(100),eth(src=f8:bc:12:44:34:b6,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=1.1.2.92,tip=1.1.2.88,op=2,sha=f8:bc:12:44:34:b6,tha=00:00:00:00:00:00)'])
 AT_CHECK([ovs-appctl netdev-dummy/receive br0 
'recirc_id(0),in_port(100),eth(src=f8:bc:12:44:34:b7,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=1.1.2.93,tip=1.1.2.88,op=2,sha=f8:bc:12:44:34:b7,tha=00:00:00:00:00:00)'])
 
-AT_CHECK([ovs-appctl tnl/neigh/show], [0], [dnl
-IPMAC Bridge
-==
+AT_CHECK([ovs-appctl tnl/neigh/show | tail -n+3 | sort], [0], [dnl
 1.1.2.92  f8:bc:12:44:34:b6   br0
 1.1.2.93  f8:bc:12:44:34:b7   br0
 ])
-- 
1.8.3.1

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

Re: [ovs-dev] [PATCH v4] netdev-dpdk: add hotplug support

[Mauricio Vásquez]

Hi Flavio,

On Tue, May 10, 2016 at 10:11 PM, Flavio Leitner  wrote:

>
> Thanks for this patch, Mauricio.
> More inline.
>
> On Tue, May 10, 2016 at 09:47:12PM +0200, Mauricio Vásquez wrote:
> > Adding in CC all the people involved.
> > (I don't know why git just takes two)
> >
> > On Tue, May 10, 2016 at 9:11 PM, Mauricio Vasquez B <
> > mauricio.vasquezber...@studenti.polito.it> wrote:
> >
> > > In order to use dpdk ports in ovs they have to be bound to a DPDK
> > > compatible driver before ovs is started.
> > >
> > > This patch adds the possibility to hotplug (or hot-unplug) a device
> > > after ovs has been started. The implementation adds an appctl command:
> > > netdev-dpdk/port-clt
> > >
> > > After the user attaches a new device, it has to be added to a bridge
> > > using the add-port command, similarly, before detaching a device
> > > it has to be removed using the del-port command.
> > >
> > > Signed-off-by: Mauricio Vasquez B <
> > > mauricio.vasquezber...@studenti.polito.it>
> > > ---
> > > v4:
> > >  - fix typo in commit message
> > >  - remove unnecessary whitespace change in INSTALL.DPDK.md
> > > v3:
> > >  - create dpdk_port_attach and dpdk_port_detach functions
> > >  - modify mutex locking order
> > > v2:
> > >  - use rte_eth_dev_is_valid_port() to check if a port is valid
> > >
> > >  INSTALL.DPDK.md   |  24 +
> > >  NEWS  |   1 +
> > >  lib/netdev-dpdk.c | 102
> > > ++
> > >  3 files changed, 120 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md
> > > index 9ec8bf6..026373d 100644
> > > --- a/INSTALL.DPDK.md
> > > +++ b/INSTALL.DPDK.md
> > > @@ -227,6 +227,29 @@ Using the DPDK with ovs-vswitchd:
> > > For more details regarding egress-policer parameters please refer
> to
> > > the
> > > vswitch.xml.
> > >
> > > +9. Port Hotplug
> > > +
> > > +   ovs supports port hotplugging, it allows to use ports that were not
> > > bound
> > > +   to DPDK when vswitchd was started.
> > > +   In order to attach a port, it has to be bound to DPDK using the
> > > +   dpdk_nic_bind.py script:
> > > +
> > > +   `$DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio :01:00.0`
> > > +
> > > +   Then it can be attached to OVS:
> > > +
> > > +   `ovs-appctl netdev-dpdk/port-ctl attach :01:00.0`
> > > +
> > > +   At this point, the user can create a ovs port using the add-port
> > > command.
> > > +
> > > +   It is also possible to detach a port from ovs, the user has to
> remove
> > > the
> > > +   port using the del-port command, then it can be detached using:
> > > +
> > > +   `ovs-appctl netdev-dpdk/port-ctl detach dpdk0`
> > > +
> > > +   This feature is not supported by all the NICs, please refer to the
> > > +   [DPDK Port Hotplug Framework] in order to get more information.
> > > +
> > >  Performance Tuning:
> > >  ---
> > >
> > > @@ -959,3 +982,4 @@ Please report problems to b...@openvswitch.org.
> > >  [INSTALL.md]:INSTALL.md
> > >  [DPDK Linux GSG]:
> > >
> http://www.dpdk.org/doc/guides/linux_gsg/build_dpdk.html#binding-and-unbinding-network-ports-to-from-the-igb-uioor-vfio-modules
> > >  [DPDK Docs]: http://dpdk.org/doc
> > > +[DPDK Port Hotplug Framework]:
> > > http://dpdk.org/doc/guides/prog_guide/port_hotplug_framework.html
> > > diff --git a/NEWS b/NEWS
> > > index ea7f3a1..2ba8659 100644
> > > --- a/NEWS
> > > +++ b/NEWS
> > > @@ -26,6 +26,7 @@ Post-v2.5.0
> > > assignment.
> > >   * Type of log messages from PMD threads changed from INFO to DBG.
> > >   * QoS functionality with sample egress-policer implementation.
> > > + * Port Hotplug is now supported.
> > > - ovs-benchmark: This utility has been removed due to lack of use
> and
> > >   bitrot.
> > > - ovs-appctl:
> > > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> > > index e09b471..cd98a2b 100644
> > > --- a/lib/netdev-dpdk.c
> > > +++ b/lib/netdev-dpdk.c
> > > @@ -599,7 +599,7 @@ dpdk_eth_dev_init(struct netdev_dpdk *dev)
> > > OVS_REQUIRES(dpdk_mutex)
> > >  int diag;
> > >  int n_rxq, n_txq;
> > >
> > > -if (dev->port_id < 0 || dev->port_id >= rte_eth_dev_count()) {
> > > +if (!rte_eth_dev_is_valid_port(dev->port_id)) {
> > >  return ENODEV;
> > >  }
> > >
> > > @@ -1985,6 +1985,89 @@ netdev_dpdk_set_admin_state(struct unixctl_conn
> > > *conn, int argc,
> > >  unixctl_command_reply(conn, "OK");
> > >  }
> > >
> > > +static int
> > > +dpdk_port_attach(const char * port, char * response, size_t size)
>
> minor nit: extra space after '*'.  Look at other functions in the
> same file.
>
>
> > > +OVS_REQUIRES(dpdk_mutex)
> > > +{
> > > +int ret;
> > > +uint8_t port_id;
> > > +
> > > +ret = rte_eth_dev_attach(port, _id);
> > > +if (ret < 0) {
> > > +snprintf(response, size, "Error attaching device '%s'", port);
> > > +return -1;
> > > +}
> > > +
> > > +

Re: [ovs-dev] [PATCH RFC] dpif-netdev: ACL+dpcls for Wildcard matching.

[Fischetti, Antonio]

From: Jarno Rajahalme [mailto:ja...@ovn.org]
Sent: Thursday, May 5, 2016 7:45 PM
To: Fischetti, Antonio 
Cc: Ben Pfaff ; dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH RFC] dpif-netdev: ACL+dpcls for Wildcard matching.


On May 5, 2016, at 9:27 AM, Fischetti, Antonio 
> wrote:

Thanks for your feedback, Jarno. Replies inline.

From: Jarno Rajahalme [mailto:ja...@ovn.org]
Sent: Wednesday, May 4, 2016 7:23 PM
To: Fischetti, Antonio 
>
Cc: Ben Pfaff >; 
dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH RFC] dpif-netdev: ACL+dpcls for Wildcard matching.


On May 4, 2016, at 3:56 AM, Fischetti, Antonio 
> wrote:

Hi Jarno, my reply inline.

Thanks,
Antonio



For more details, please let me know.

The flows above are at the OpenFlow level. I guess your test traffic
exercises (just) the corresponding datapath flows?

Do you know how much of the performance gain is lost once you add
support not just for the IPv4 5-tuple, but all the different fields
supported by struct flow (metadata, L2, IPv6, ARP, IGMP, etc)?

[Antonio F]
I didn't make these kind of tests yet, for now I restricted
my tests focusing only on the wildcard matching for megaflows.
I tried to exclude any other aspect that could affect the
overall performance, I wanted to check if this solution is
really an improvement for the wildcard matching.

When we consider that also other tables are involved, the lookups and
jumps between ofproto tables, EMC lookups and so on,
of course the performance gain will have less impact on the overall
system.

The performance figures are just for the IPv4 5-tuple, but I needed
to share the idea and have some feedback from the Community
before moving forward.



I’ve found that typically you have to implement the whole thing to find out if 
it makes a significant difference or not.

This solution as proposed could be characterized as another cache between the 
EMC cache and themegaflow classifier.
[Antonio F] That’s an interesting idea.

One major factor that will determine its usefulness is the fraction of time it 
is operational in a realistic traffic situation. I haven’t fully read the code, 
but it seems to me that DPDK-ACL lookup can only be done if there are no 
pending changes to the megaflows.
[Antonio F] Exactly, or when a ‘rebuild’ is in progress.
An ACL insertion is a 2-step process: the insertion itself and then the 
so-called ‘rebuild’.
The rebuild may require a lot of cpu cycles, it depends on how many entries are 
already in the table.
I made some measurements, with 1000 entries the rebuild requires approx. 
66,000,000 CPU cycles.
With 10,000 entries  => 1,500,000,000 CPU cycles.


If the DPDK-ACL was a cache, then we could limit the number of entries to 
something that makes sense.

[Antonio F] That’s interesting. If I understand well your idea is that at the 
start up we should use the original dpcls and populate ACL in the background. 
After a limit of entries is reached, or after some time limit, the ACL cache is 
ready to work between the EMC and the dpcls. At this point no further entry can 
be added, deletion can be made as ‘fast’ deletions by deleting the 
intermediate-table entries.


Since there typically is high churn in the megaflow classifier
[Antonio F] TBH I don’t know exactly how much frequent are the Flow 
insertions/removals in a real scenario.


In the worst case each new L4 connection may require a megaflow update. This 
should not be typical, though, as we strive to generate megaflows that are not 
5-tuple specific.



due to it being reactive to the actual network traffic, especially if compared 
to the OpenFlowclassifier, which is reactive to configuration and policy 
changes only, the fraction of time when the DPDK-ACL can be operational might 
be low.

If you were able to change the DPDK-ACL structure to allow fast removal (i.e., 
by marking an entry invalid), it might be possible to keep it operational as a 
cache on front of the megaflow classifier at all times; if there is a miss on 
the DPDK-ACL, then we would proceed to do a lookup in themegaflow classifier.
[Antonio F] Unluckly ACL doesn’t allow to update its entries.


Right, but when an entry is found, it could be marked as “deleted” outside of 
the ACL, meaning that a megaflow classifier lookup needs to be made.

[Antonio F] That can be easily done as it is now. ACL can store {key, value} 
entries where the value is 32bit long. When an entry is found the value is not 
a pointer to the Flow, it’s just an index to an intermediate table, which is an 
array of Flow pointers.

  Jarno


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

[ovs-dev] Emailing: Photo 05-11-2016, 59 37 85

[dev]

Your message is ready to be sent with the following file or link
attachments:

Photo 05-11-2016, 59 37 85


Note: To protect against computer viruses, e-mail programs may prevent
sending or receiving certain types of file attachments.  Check your e-mail
security settings to determine how attachments are handled.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v3 2/3] netdev-dpdk: Add vHost User PMD

[Ciara Loftus]

DPDK 16.04 introduces the vHost PMD which allows 'dpdkvhostuser' ports
to be controlled by the librte_ether API, like physical 'dpdk' ports.
The commit integrates this functionality into OVS, and refactors some
of the existing vhost code such that it is vhost-cuse specific.
Similarly, there is now some overlap between dpdk and vhost-user port
code.

Signed-off-by: Ciara Loftus 
---
 INSTALL.DPDK.md   |  12 ++
 NEWS  |   2 +
 lib/netdev-dpdk.c | 628 +-
 3 files changed, 396 insertions(+), 246 deletions(-)

diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md
index 93f92e4..db7153a 100644
--- a/INSTALL.DPDK.md
+++ b/INSTALL.DPDK.md
@@ -990,6 +990,18 @@ Restrictions:
 increased to the desired number of queues. Both DPDK and OVS must be
 recompiled for this change to take effect.
 
+  DPDK 'eth' type ports:
+  - dpdk, dpdkr and dpdkvhostuser ports are 'eth' type ports in the context of
+DPDK as they are all managed by the rte_ether API. This means that they
+adhere to the DPDK configuration option CONFIG_RTE_MAX_ETHPORTS which by
+default is set to 32. This means by default the combined total number of
+dpdk, dpdkr and dpdkvhostuser ports allowable in OVS with DPDK is 32. This
+value can be changed if desired by modifying the configuration file in
+DPDK, or by overriding the default value on the command line when building
+DPDK. eg.
+
+`make install CONFIG_RTE_MAX_ETHPORTS=64`
+
 Bug Reporting:
 --
 
diff --git a/NEWS b/NEWS
index 4e81cad..841314b 100644
--- a/NEWS
+++ b/NEWS
@@ -32,6 +32,8 @@ Post-v2.5.0
  * DB entries have been added for many of the DPDK EAL command line
arguments. Additional arguments can be passed via the dpdk-extra
entry.
+ * vHost PMD integration brings vhost-user ports under control of the
+   rte_ether DPDK API.
- ovs-benchmark: This utility has been removed due to lack of use and
  bitrot.
- ovs-appctl:
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 89d783a..814ef83 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -55,6 +55,7 @@
 #include "unixctl.h"
 
 #include "rte_config.h"
+#include "rte_eth_vhost.h"
 #include "rte_mbuf.h"
 #include "rte_meter.h"
 #include "rte_virtio_net.h"
@@ -139,6 +140,11 @@ static char *cuse_dev_name = NULL;/* Character device 
cuse_dev_name. */
 #endif
 static char *vhost_sock_dir = NULL;   /* Location of vhost-user sockets */
 
+/* Array that tracks the used & unused vHost user driver IDs */
+static unsigned int vhost_user_drv_ids[RTE_MAX_ETHPORTS];
+/* Maximum string length allowed to provide to rte_eth_attach function */
+#define DEVARGS_MAX (RTE_ETH_NAME_MAX_LEN + PATH_MAX + 18)
+
 /*
  * Maximum amount of time in micro seconds to try and enqueue to vhost.
  */
@@ -172,7 +178,8 @@ enum { DRAIN_TSC = 20ULL };
 
 enum dpdk_dev_type {
 DPDK_DEV_ETH = 0,
-DPDK_DEV_VHOST = 1,
+DPDK_DEV_VHOST_USER = 1,
+DPDK_DEV_VHOST_CUSE = 2,
 };
 
 static int rte_eal_init_ret = ENODEV;
@@ -358,12 +365,22 @@ struct netdev_dpdk {
 int real_n_rxq;
 bool txq_needs_locking;
 
-/* virtio-net structure for vhost device */
+/* Spinlock for vhost cuse transmission. Other DPDK devices use spinlocks
+ * in dpdk_tx_queue */
+rte_spinlock_t vhost_cuse_tx_lock;
+
+/* virtio-net structure for vhost cuse device */
 OVSRCU_TYPE(struct virtio_net *) virtio_dev;
 
+/* Number of virtqueue pairs reported by the guest */
+uint32_t vhost_qp_nb;
+
 /* Identifier used to distinguish vhost devices from each other */
 char vhost_id[PATH_MAX];
 
+/* ID of vhost user port given to the PMD driver */
+unsigned int vhost_pmd_id;
+
 /* In dpdk_list. */
 struct ovs_list list_node OVS_GUARDED_BY(dpdk_mutex);
 
@@ -381,16 +398,20 @@ struct netdev_rxq_dpdk {
 static bool dpdk_thread_is_pmd(void);
 
 static int netdev_dpdk_construct(struct netdev *);
+static int netdev_dpdk_vhost_user_construct(struct netdev *);
 
 struct virtio_net * netdev_dpdk_get_virtio(const struct netdev_dpdk *dev);
 
 void link_status_changed_callback(uint8_t port_id,
 enum rte_eth_event_type type OVS_UNUSED, void *param OVS_UNUSED);
+void vring_state_changed_callback(uint8_t port_id,
+enum rte_eth_event_type type OVS_UNUSED, void *param OVS_UNUSED);
 
 static bool
-is_dpdk_class(const struct netdev_class *class)
+is_dpdk_eth_class(const struct netdev_class *class)
 {
-return class->construct == netdev_dpdk_construct;
+return ((class->construct == netdev_dpdk_construct) ||
+(class->construct == netdev_dpdk_vhost_user_construct));
 }
 
 /* DPDK NIC drivers allocate RX buffers at a particular granularity, typically
@@ -592,7 +613,12 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, int 
n_rxq, int n_txq)
 }
 
 dev->up.n_rxq = n_rxq;
-dev->real_n_txq = n_txq;
+/* Only set real_n_txq for 

[ovs-dev] [PATCH v3 1/3] netdev-dpdk: Remove dpdk watchdog thread

[Ciara Loftus]

Instead of continuously polling for link status changes on 'dpdk'
ports, register a callback function that will be triggered when DPDK
detects that the link status of that port has changed.

Signed-off-by: Ciara Loftus 
Suggested-by: Kevin Traynor 
---
 lib/netdev-dpdk.c | 55 ++-
 1 file changed, 30 insertions(+), 25 deletions(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index af86d19..89d783a 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -62,8 +62,6 @@
 VLOG_DEFINE_THIS_MODULE(dpdk);
 static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 20);
 
-#define DPDK_PORT_WATCHDOG_INTERVAL 5
-
 #define OVS_CACHE_LINE_SIZE CACHE_LINE_SIZE
 #define OVS_VPORT_DPDK "ovs_dpdk"
 
@@ -386,6 +384,9 @@ static int netdev_dpdk_construct(struct netdev *);
 
 struct virtio_net * netdev_dpdk_get_virtio(const struct netdev_dpdk *dev);
 
+void link_status_changed_callback(uint8_t port_id,
+enum rte_eth_event_type type OVS_UNUSED, void *param OVS_UNUSED);
+
 static bool
 is_dpdk_class(const struct netdev_class *class)
 {
@@ -536,27 +537,6 @@ check_link_status(struct netdev_dpdk *dev)
 }
 }
 
-static void *
-dpdk_watchdog(void *dummy OVS_UNUSED)
-{
-struct netdev_dpdk *dev;
-
-pthread_detach(pthread_self());
-
-for (;;) {
-ovs_mutex_lock(_mutex);
-LIST_FOR_EACH (dev, list_node, _list) {
-ovs_mutex_lock(>mutex);
-check_link_status(dev);
-ovs_mutex_unlock(>mutex);
-}
-ovs_mutex_unlock(_mutex);
-xsleep(DPDK_PORT_WATCHDOG_INTERVAL);
-}
-
-return NULL;
-}
-
 static int
 dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, int n_rxq, int n_txq)
 {
@@ -717,6 +697,27 @@ netdev_dpdk_alloc_txq(struct netdev_dpdk *dev, unsigned 
int n_txqs)
 }
 }
 
+void
+link_status_changed_callback(uint8_t port_id,
+  enum rte_eth_event_type type OVS_UNUSED,
+  void *param OVS_UNUSED)
+{
+struct netdev_dpdk *dev;
+
+ovs_mutex_lock(_mutex);
+LIST_FOR_EACH (dev, list_node, _list) {
+if (port_id == dev->port_id) {
+ovs_mutex_lock(>mutex);
+check_link_status(dev);
+ovs_mutex_unlock(>mutex);
+break;
+}
+}
+ovs_mutex_unlock(_mutex);
+
+return;
+}
+
 static int
 netdev_dpdk_init(struct netdev *netdev, unsigned int port_no,
  enum dpdk_dev_type type)
@@ -774,6 +775,12 @@ netdev_dpdk_init(struct netdev *netdev, unsigned int 
port_no,
 netdev_dpdk_alloc_txq(dev, OVS_VHOST_MAX_QUEUE_NUM);
 }
 
+if (type == DPDK_DEV_ETH) {
+rte_eth_dev_callback_register(port_no, RTE_ETH_EVENT_INTR_LSC,
+ (void*)link_status_changed_callback,
+  NULL);
+}
+
 ovs_list_push_back(_list, >list_node);
 
 unlock:
@@ -3207,8 +3214,6 @@ dpdk_init__(const struct smap *ovs_other_config)
 /* We are called from the main thread here */
 RTE_PER_LCORE(_lcore_id) = NON_PMD_CORE_ID;
 
-ovs_thread_create("dpdk_watchdog", dpdk_watchdog, NULL);
-
 #ifdef VHOST_CUSE
 /* Register CUSE device to handle IOCTLs.
  * Unless otherwise specified, cuse_dev_name is set to vhost-net.
-- 
2.4.3

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

[ovs-dev] [PATCH v3 0/3] vHost PMD

[Ciara Loftus]

This series adds the vHost User PMD.

Previous: http://openvswitch.org/pipermail/dev/2016-May/070745.html

v3:
* keep vhost user txq mapping
* refactored locking logic around dpdk, dpdkr and vhost send functions

v2:
* rebase
* split into 3-part series
* remove dpdk watchdog - use link status change interrupt calllbacks
instead
* fix del-port problems - only set vhost_pmd_id once
* vhost user feature disable reintroduced using PMD function
* fix: txq locking for dpdk not removed
* set correct stats for vhost-user (some not supported)
* fix get_status for vhost (some values not set by PMD)
* unlock dpdk mutex upon cuse_construct failure
* string check for comma in vhost socket name
* check if txq locking needed during vring_state_changed callback
* various tidy up, additional logging & comments

  netdev-dpdk: Remove dpdk watchdog thread
  netdev-dpdk: Add vHost User PMD
  netdev-dpdk: Add vhost-user 'get_features' & 'get_status' functions

 INSTALL.DPDK.md   |  12 +
 NEWS  |   2 +
 lib/netdev-dpdk.c | 704 --
 3 files changed, 438 insertions(+), 280 deletions(-)

-- 
2.4.3

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

Re: [ovs-dev] [ovs-dev,v2,2/3] netdev-dpdk: Add vHost User PMD

[Loftus, Ciara]

> On 10.05.2016 12:25, Ciara Loftus wrote:
> > DPDK 16.04 introduces the vHost PMD which allows 'dpdkvhostuser' ports
> > to be controlled by the librte_ether API, like physical 'dpdk' ports.
> > The commit integrates this functionality into OVS, and refactors some
> > of the existing vhost code such that it is vhost-cuse specific.
> > Similarly, there is now some overlap between dpdk and vhost-user port
> > code.
> >
> > Signed-off-by: Ciara Loftus 
> > ---
> >  INSTALL.DPDK.md   |  12 ++
> >  NEWS  |   2 +
> >  lib/netdev-dpdk.c | 493 ++
> 
> >  3 files changed, 248 insertions(+), 259 deletions(-)
> >
> > diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md
> > index 93f92e4..db7153a 100644
> > --- a/INSTALL.DPDK.md
> > +++ b/INSTALL.DPDK.md
> > @@ -990,6 +990,18 @@ Restrictions:
> >  increased to the desired number of queues. Both DPDK and OVS must
> be
> >  recompiled for this change to take effect.
> >
> > +  DPDK 'eth' type ports:
> > +  - dpdk, dpdkr and dpdkvhostuser ports are 'eth' type ports in the context
> of
> > +DPDK as they are all managed by the rte_ether API. This means that
> they
> > +adhere to the DPDK configuration option CONFIG_RTE_MAX_ETHPORTS
> which by
> > +default is set to 32. This means by default the combined total number 
> > of
> > +dpdk, dpdkr and dpdkvhostuser ports allowable in OVS with DPDK is 32.
> This
> > +value can be changed if desired by modifying the configuration file in
> > +DPDK, or by overriding the default value on the command line when
> building
> > +DPDK. eg.
> > +
> > +`make install CONFIG_RTE_MAX_ETHPORTS=64`
> > +
> >  Bug Reporting:
> >  --
> >
> > diff --git a/NEWS b/NEWS
> > index 4e81cad..841314b 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -32,6 +32,8 @@ Post-v2.5.0
> >   * DB entries have been added for many of the DPDK EAL command line
> > arguments. Additional arguments can be passed via the dpdk-extra
> > entry.
> > + * vHost PMD integration brings vhost-user ports under control of the
> > +   rte_ether DPDK API.
> > - ovs-benchmark: This utility has been removed due to lack of use and
> >   bitrot.
> > - ovs-appctl:
> > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> > index 89d783a..0e5b141 100644
> > --- a/lib/netdev-dpdk.c
> > +++ b/lib/netdev-dpdk.c
> > @@ -55,6 +55,7 @@
> >  #include "unixctl.h"
> >
> >  #include "rte_config.h"
> > +#include "rte_eth_vhost.h"
> >  #include "rte_mbuf.h"
> >  #include "rte_meter.h"
> >  #include "rte_virtio_net.h"
> > @@ -139,6 +140,11 @@ static char *cuse_dev_name = NULL;/*
> Character device cuse_dev_name. */
> >  #endif
> >  static char *vhost_sock_dir = NULL;   /* Location of vhost-user sockets */
> >
> > +/* Array that tracks the used & unused vHost user driver IDs */
> > +static unsigned int vhost_user_drv_ids[RTE_MAX_ETHPORTS];
> > +/* Maximum string length allowed to provide to rte_eth_attach function
> */
> > +#define DEVARGS_MAX (RTE_ETH_NAME_MAX_LEN + PATH_MAX + 18)
> > +
> >  /*
> >   * Maximum amount of time in micro seconds to try and enqueue to vhost.
> >   */
> > @@ -172,7 +178,8 @@ enum { DRAIN_TSC = 20ULL };
> >
> >  enum dpdk_dev_type {
> >  DPDK_DEV_ETH = 0,
> > -DPDK_DEV_VHOST = 1,
> > +DPDK_DEV_VHOST_USER = 1,
> > +DPDK_DEV_VHOST_CUSE = 2,
> >  };
> >
> >  static int rte_eal_init_ret = ENODEV;
> > @@ -304,8 +311,6 @@ struct dpdk_tx_queue {
> >  * from concurrent access.  It is used 
> > only
> >  * if the queue is shared among 
> > different
> >  * pmd threads (see 
> > 'txq_needs_locking'). */
> > -int map;   /* Mapping of configured vhost-user 
> > queues
> > -* to enabled by guest. */
> >  uint64_t tsc;
> >  struct rte_mbuf *burst_pkts[MAX_TX_QUEUE_LEN];
> >  };
> > @@ -358,12 +363,22 @@ struct netdev_dpdk {
> >  int real_n_rxq;
> >  bool txq_needs_locking;
> >
> > -/* virtio-net structure for vhost device */
> > +/* Spinlock for vhost cuse transmission. Other DPDK devices use
> spinlocks
> > + * in dpdk_tx_queue */
> > +rte_spinlock_t vhost_cuse_tx_lock;
> > +
> > +/* virtio-net structure for vhost cuse device */
> >  OVSRCU_TYPE(struct virtio_net *) virtio_dev;
> >
> > +/* Number of virtqueue pairs reported by the guest */
> > +uint32_t vhost_qp_nb;
> > +
> >  /* Identifier used to distinguish vhost devices from each other */
> >  char vhost_id[PATH_MAX];
> >
> > +/* ID of vhost user port given to the PMD driver */
> > +unsigned int vhost_pmd_id;
> > +
> >  /* In dpdk_list. */
> >  struct ovs_list list_node OVS_GUARDED_BY(dpdk_mutex);
> >
> > @@ -381,16 +396,20 @@ struct netdev_rxq_dpdk {
> >  static bool dpdk_thread_is_pmd(void);
> >
> >  

[ovs-dev] [PATCH v3 3/3] netdev-dpdk: Add vhost-user 'get_features' & 'get_status' functions

[Ciara Loftus]

Implementations for the netdev functions 'get_features' and
'get_status' are now available for vhost-user thanks to the addition of
the vHost PMD.

Signed-off-by: Ciara Loftus 
---
 lib/netdev-dpdk.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 814ef83..fce1655 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -2301,15 +2301,18 @@ netdev_dpdk_get_status(const struct netdev *netdev, 
struct smap *args)
 smap_add_format(args, "max_rx_queues", "%u", dev_info.max_rx_queues);
 smap_add_format(args, "max_tx_queues", "%u", dev_info.max_tx_queues);
 smap_add_format(args, "max_mac_addrs", "%u", dev_info.max_mac_addrs);
-smap_add_format(args, "max_hash_mac_addrs", "%u", 
dev_info.max_hash_mac_addrs);
-smap_add_format(args, "max_vfs", "%u", dev_info.max_vfs);
-smap_add_format(args, "max_vmdq_pools", "%u", dev_info.max_vmdq_pools);
 
-if (dev_info.pci_dev) {
-smap_add_format(args, "pci-vendor_id", "0x%u",
-dev_info.pci_dev->id.vendor_id);
-smap_add_format(args, "pci-device_id", "0x%x",
-dev_info.pci_dev->id.device_id);
+if (dev->type == DPDK_DEV_ETH) {
+smap_add_format(args, "max_hash_mac_addrs", "%u",
+dev_info.max_hash_mac_addrs);
+smap_add_format(args, "max_vfs", "%u", dev_info.max_vfs);
+smap_add_format(args, "max_vmdq_pools", "%u", dev_info.max_vmdq_pools);
+if (dev_info.pci_dev) {
+smap_add_format(args, "pci-vendor_id", "0x%u",
+dev_info.pci_dev->id.vendor_id);
+smap_add_format(args, "pci-device_id", "0x%x",
+dev_info.pci_dev->id.device_id);
+}
 }
 
 return 0;
@@ -3431,8 +3434,8 @@ static const struct netdev_class OVS_UNUSED 
dpdk_vhost_user_class =
 netdev_dpdk_vhost_user_send,
 netdev_dpdk_get_carrier,
 netdev_dpdk_get_stats,
-NULL,
-NULL,
+netdev_dpdk_get_features,
+netdev_dpdk_get_status,
 netdev_dpdk_vhost_user_rxq_recv);
 
 void
-- 
2.4.3

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

[ovs-dev] ShoreTel Customers DB

[sonia young]

Hey,

 

Are you searching for securing the rundown of clients or organizations
utilizing ShoreTel We give the 

Database crosswise over North America, EMEA, APAC and Latin America. 

 

Data Fields: Name, Email, Title, Phone, Web Address, Physical Address, SIC
Codes and what innovation they utilize. 

 

We likewise have other innovation clients like: 

 

*  Cisco

*  Mitel

*  Ringcentral

*  Avaya and some more. 

 

If it's not too much trouble let me know your considerations with the goal
that I can send you cost of the rundown.

 

Value your time and anticipate get notification from you on the off chance
that you are not the correct individual, don't hesitate to forward this
email to the ideal individual in your association. 

 

Respects,

Sonia Young

 

Request Generation

 

On the off chance that you would prefer not to incorporate yourself in our
mailing list, please answer back "Forget" in a title

 

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

[ovs-dev] Data plane traffic detection

[Daniele Venturino]

Hi,
which is the best entry point to identify traffic among hosts connected to a 
OVS switch and not pertaining the control plane when the OVS switch is managed 
by a SDN controller?
​
Best regards,
Daniele Venturino 

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

Re: [ovs-dev] [PATCH v9 net-next 4/7] openvswitch: add layer 3 flow/port support

[Jiri Benc]

On Wed, 11 May 2016 12:06:35 +0900, Simon Horman wrote:
> Is this close to what you had in mind?

Yes but see below.

> @@ -739,17 +729,17 @@ int ovs_flow_key_extract(const struct ip_tunnel_info 
> *tun_info,
>   key->phy.skb_mark = skb->mark;
>   ovs_ct_fill_key(skb, key);
>   key->ovs_flow_hash = 0;
> - key->phy.is_layer3 = is_layer3;
> + key->phy.is_layer3 = (tun_info && skb->mac_len == 0);

Do we have to depend on tun_info? It would be nice to support all
ARPHRD_NONE interfaces, not just tunnels. The tun interface (from
the tuntap driver) comes to mind, for example.

> --- a/net/openvswitch/vport-netdev.c
> +++ b/net/openvswitch/vport-netdev.c
> @@ -60,7 +60,21 @@ static void netdev_port_receive(struct sk_buff *skb)
>   if (vport->dev->type == ARPHRD_ETHER) {
>   skb_push(skb, ETH_HLEN);
>   skb_postpush_rcsum(skb, skb->data, ETH_HLEN);
> + } else if (vport->dev->type == ARPHRD_NONE) {
> + if (skb->protocol == htons(ETH_P_TEB)) {
> + struct ethhdr *eth = eth_hdr(skb);
> +
> + if (unlikely(skb->len < ETH_HLEN))
> + goto error;
> +
> + skb->mac_len = ETH_HLEN;
> + if (eth->h_proto == htons(ETH_P_8021Q))
> + skb->mac_len += VLAN_HLEN;
> + } else {
> + skb->mac_len = 0;
> + }

Without putting much thought into this, could this perhaps be left for
parse_ethertype (called from key_extract) to do?

Thanks,

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

Re: [ovs-dev] [PATCH v9 net-next 4/7] openvswitch: add layer 3 flow/port support

[Jiri Benc]

On Wed, 11 May 2016 12:28:14 +0900, Simon Horman wrote:
> I think that at this stage I would prefer to prohibit push_eth() acting
> on a packet which already has an ethernet header. Indeed that is what
> my patch-set already does in its modifications of __ovs_nla_copy_actions().
> 
> The reason that I lean towards prohibiting this is that I do not
> have an easy way to exercise this case within the current patch-set.
> And thus this extra complexity seems well suited to being handled handled
> incrementally as further work.

Works for me. I don't see any real usage for multiple Ethernet headers.

Thanks!

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

[ovs-dev] New Group Mod command to add or modify group

[Jan Scheurich]

In OpenFlow 1.x the Group Mod commands OFPGC_ADD and OFPGC_MODIFY have strict 
semantics: ADD fails if the group exists, while MODIFY fails if the group does 
not exist.

This requires a controller to exactly know the state of the switch when 
programming a group in order not run the risk of getting an OFP Error message 
in response. This is hard to achieve and maintain in view of possible switch 
and controller restarts or other connection losses between switch and 
controller.

Due to the un-acknowledged nature of the Group Mod message programming groups 
safely and efficiently at the same time is virtually impossible as the 
controller has to either query the existence of the group prior to each Group 
Mod message or to insert a Barrier Request/Reply after every group to be sure 
that no Error can be received at a later stage and require a complicated 
roll-back of any dependent actions taken between the failed Group Mod and the 
Error.

A simple solution to this problem would be an additional, more tolerant Group 
Mod command (e.g. ADD_OR_MODIFY) that writes a group into the group table no 
matter if it already existed in the switch or not. A similar proposal was 
submitted to ONF a while ago but never implemented in the OpenFlow standard 
(https://rs.opennetworking.org/bugs/browse/EXT-41).

Would the OVS community be open to implement this additional Group Mod command 
for OpenFlow protocol 1.3 and later?

BR, Jan

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

[ovs-dev] Test

[keisern]

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

[ovs-dev] Skoll Philanthropic Foundation.

[Slattery Esther (NORTH EAST LONDON NHS FOUNDATION TRUST)]

Message from Skoll Philanthropic Foundation. You been selected for a donation 
of $5Million Dollars. Contact Via email  
rainer.ro...@yandex.com



This message may contain confidential information. If you are not the intended 
recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take 
any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff 
in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information 
with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be 
accessed anywhere


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

Re: [ovs-dev] vendors

[Jenifer Bernard]

hello dev,

 

You may refer to the attached document for details.

 

Regards,

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

Re: [ovs-dev] Items

[Tonya Mueller]

hello dev,

 

You may refer to the attached document for details.

 

Regards,

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

Re: [ovs-dev] build assemblies

[Velma Watkins]

hello dev,

 

You may refer to the attached document for details.

 

Regards,

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

[ovs-dev] User-space tunneling only on LOCAL port?

[Jan Scheurich]

We are trying to set up user-space tunneling with DPDK datapath in OVS 2.5 
using other internal ports on the external bridge (br-prv) than the LOCAL 
bridge port as local tunnel end-points. The ultimate goal is to configure the 
different internal ports on br-prv as VLAN access ports with different tags to 
separate the tunnel traffic into a number of VLANs on the physical underlay.

However, we experience that even though OVS can be configured for this and is 
able to resolve the remote tunnel end-point, the data plane does not work. 
Packets are  being dropped on egress into the tunnel port. In the other 
direction, tunneled packets received on br-prv are forwarded to port tep1 with 
VXLAN encapsulation.

The data plane only works as expected if the LOCAL port of the external bridge 
is configured as local tunnel end-point.

Is this limitation intended? Or is it simply a short-cut to simplify the 
implementation of user-space tunneling?

Here is our configuration in details:

# ovs-vsctl show
176cb2b1-0ebe-4490-9210-f60434f09cc9
Bridge br_int
Port br_int
Interface br_int
type: internal
Port "vxlan0"
Interface "vxlan0"
type: vxlan
options: {key=flow, remote_ip="10.1.2.9"}
Bridge br-prv
Port br-prv
tag: 100
Interface br-prv
type: internal
Port bond-dpdk
Interface "dpdk0"
type: dpdk
Interface "dpdk1"
type: dpdk
Port "tep1"
Interface "tep1"
type: internal

# ifconfig -a
br_intLink encap:Ethernet  HWaddr 66:e2:69:60:dc:42
  inet addr:172.1.1.8  Bcast:172.1.1.255  Mask:255.255.255.0
  inet6 addr: fe80::64e2:69ff:fe60:dc42/64 Scope:Link
  UP BROADCAST RUNNING PROMISC  MTU:1500  Metric:1
  RX packets:391 errors:0 dropped:391 overruns:0 frame:0
  TX packets:803 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:500
  RX bytes:16722 (16.7 KB)  TX bytes:34038 (34.0 KB)

br-prvLink encap:Ethernet  HWaddr 8c:dc:d4:ab:5b:f0
  BROADCAST PROMISC  MTU:1500  Metric:1
  RX packets:23 errors:0 dropped:0 overruns:0 frame:0
  TX packets:191 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:500
  RX bytes:1712 (1.7 KB)  TX bytes:8334 (8.3 KB)

tep1  Link encap:Ethernet  HWaddr c2:cf:a0:d4:f4:d6
  inet addr:10.1.3.8  Bcast:10.1.3.255  Mask:255.255.255.0
  inet6 addr: fe80::c0cf:a0ff:fed4:f4d6/64 Scope:Link
  UP BROADCAST RUNNING PROMISC  MTU:1500  Metric:1
  RX packets:3328 errors:0 dropped:2682 overruns:0 frame:0
  TX packets:127 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:500
  RX bytes:231004 (231.0 KB)  TX bytes:11454 (11.4 KB)

# ip route
10.1.2.0/24 via 10.1.3.1 dev tep1
10.1.3.0/24 dev tep1  proto kernel  scope link  src 10.1.3.8
172.1.1.0/24 dev br_int  proto kernel  scope link  src 172.1.1.8

Apparently OVS is able to correctly resolve the VXLAN tunnel to the internal 
port tep1 as local end point.

# ovs-appctl ovs/route/show
Route Table:
Cached: 10.1.3.8/32 dev tep1
Cached: 172.1.1.8/32 dev br_int
Cached: ::1/128 dev lo
Cached: 10.1.2.0/24 dev tep1 GW 10.1.3.1
Cached: 10.1.3.0/24 dev tep1
Cached: 172.1.1.0/24 dev br_int
Cached: 127.0.0.0/8 dev lo
Cached: 0.0.0.0/0 dev eth0 GW 10.87.247.1

# ovs-appctl tnl/neigh/show
IPMAC Bridge
==
10.1.3.8  c2:cf:a0:d4:f4:d6   br-prv
10.1.3.1  00:04:96:98:78:18   br_int
10.1.3.1  00:04:96:98:78:18   br-prv
172.1.1.8 66:e2:69:60:dc:42   br_int

# ovs-vsctl list interface vxlan0
_uuid   : b2a26291-fc5c-448c-921e-c6216b24caf7
admin_state : up
...
mac_in_use  : "1e:84:2f:1e:69:7a"
mtu : []
name: "vxlan0"
ofport  : 100
ofport_request  : 100
options : {key=flow, remote_ip="10.1.2.9"}
other_config: {}
statistics  : {collisions=0, rx_bytes=0, rx_crc_err=0, rx_dropped=0, 
rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0, tx_bytes=64324, 
tx_dropped=0, tx_errors=0, tx_packets=1185}
status  : {tunnel_egress_iface="tep1", 
tunnel_egress_iface_carrier=up}
type: vxlan

In the ofproto-dpif code handling de-tunneling there seems to be an explicit 
check on OFPP_LOCAL as egress port. Should other internal ports work if we just 
remove the check?

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 15ca565..acc8376 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -3165,8 +3165,7 @@ 

Re: [ovs-dev] wachtwoord verlopen

[Ann Vanden Boer]

Van: Ann Vanden Boer
Verzonden: woensdag 11 mei 2016 11:58
Aan: Ann Vanden Boer
Onderwerp: wachtwoord verlopen

Beste E-mail gebruiker.

Uw Outlook e-mail account wachtwoord vandaag vervalt, en u wordt verzocht om te 
upgraden binnen 24 uur of anders uw Outlook-e-mailaccount zal uitschakelen om 
te upgraden zijn.

Gelieve Klik UPGRADE en volg de 
instructies.

Help Desk Administrator.
ICT helpdesk
Admin team
© Copyright © 2016 Microsoft
Alle rechten voorbehouden
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] wachtwoord verlopen

[Ann Vanden Boer]

Van: Ann Vanden Boer
Verzonden: woensdag 11 mei 2016 11:58
Aan: Ann Vanden Boer
Onderwerp: wachtwoord verlopen

Beste E-mail gebruiker.

Uw Outlook e-mail account wachtwoord vandaag vervalt, en u wordt verzocht om te 
upgraden binnen 24 uur of anders uw Outlook-e-mailaccount zal uitschakelen om 
te upgraden zijn.

Gelieve Klik UPGRADE en volg de 
instructies.

Help Desk Administrator.
ICT helpdesk
Admin team
© Copyright © 2016 Microsoft
Alle rechten voorbehouden
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] credit card charges

[Dona Morris]

hello dev,

 

You may refer to the attached document for details.

 

Regards,

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

Re: [ovs-dev] [PATCH] netdev-dpdk: add sflow support for vhost-user ports

[Kavanagh, Mark B]

>
>Hi Mark,
>
>Replies inline prefixed with [PL].
>
>Thanks,
>Przemek
>
>-Original Message-
>From: Kavanagh, Mark B
>Sent: Thursday, May 5, 2016 2:19 PM
>To: Lal, PrzemyslawX ; dev@openvswitch.org
>Subject: RE: [PATCH] netdev-dpdk: add sflow support for vhost-user ports
>
>Hi Przemek,
>
>Some additional comments/queries inline.
>
>Thanks again,
>Mark
>
>>
>>This patch adds sFlow support for DPDK vHost-user interfaces by
>>assigning ifindex value. Values of ifindexes for vHost-user interfaces
>>start with 2000 to avoid overlapping with kernel datapath interfaces.
>>
>>Patch also fixes issue with 'dpdk0' interface being ignored by sFlow
>>agent, because of ifindex 0. Ifindexes values for physical DPDK
>>interfaces start with 1000 to avoid overlapping with kernel datapath 
>>interfaces.
>>
>>Signed-off-by: Przemyslaw Lal 
>>---
>> lib/netdev-dpdk.c | 70
>>++-
>> 1 file changed, 69 insertions(+), 1 deletion(-)
>>
>>diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index
>>208c5f5..1b60c5a 100644
>>--- a/lib/netdev-dpdk.c
>>+++ b/lib/netdev-dpdk.c
>>@@ -115,6 +115,18 @@ static char *vhost_sock_dir = NULL;   /* Location of 
>>vhost-user sockets
>>*/
>>  */
>> #define VHOST_ENQ_RETRY_USECS 100
>>
>>+/* For DPDK ETH interfaces use ifindex values starting with 1000
>>+ * to avoid overlapping with kernel-space interfaces.
>>+ * Also starting with 0 would cause sFlow to ignore 'dpdk0' interface.
>>+ */
>>+#define DPDK_PORT_ID_TO_IFINDEX(port_id) ((port_id) + 1000)
>>+
>>+/* For DPDK vhost-user interfaces use ifindexes starting with 2000.
>>+ */
>>+#define VHOST_ID_TO_IFINDEX(port_id) ((port_id) + 2000)
>>+
>>+#define VHOST_IDS_MAX_LEN 1024
>>+
>> static const struct rte_eth_conf port_conf = {
>> .rxmode = {
>> .mq_mode = ETH_MQ_RX_RSS,
>>@@ -149,6 +161,7 @@ enum dpdk_dev_type {  static int rte_eal_init_ret =
>>ENODEV;
>>
>> static struct ovs_mutex dpdk_mutex = OVS_MUTEX_INITIALIZER;
>>+static struct ovs_mutex vhost_mutex = OVS_MUTEX_INITIALIZER;
>>
>> /* Quality of Service */
>>
>>@@ -790,6 +803,50 @@ netdev_dpdk_vhost_cuse_construct(struct netdev *netdev)
>> return err;
>> }
>>
>>+/* Counter for VHOST interfaces as DPDK library doesn't provide
>>+mechanism
>>+ * similar to rte_eth_dev_count for vhost-user sockets.
>>+ */
>>+static int vhost_counter OVS_GUARDED_BY(vhost_mutex) = 0;
>>+
>>+/* Array storing vhost_ids, so their ifindex can be reused after
>>+socket
>>+ * recreation.
>>+ */
>>+static char vhost_ids[VHOST_IDS_MAX_LEN][PATH_MAX]
>>+OVS_GUARDED_BY(vhost_mutex);
>>+
>>+/* Simple lookup in vhost_ids array.
>>+ * On success returns id of vhost_id stored in the array,
>>+ * otherwise returns -1.
>>+ */
>>+static int
>>+netdev_dpdk_lookup_vhost_id(struct netdev_dpdk *dev)
>>+OVS_REQUIRES(vhost_mutex) {
>>+for (int i = 0; i < vhost_counter; i++) {
>>+if (strncmp(vhost_ids[i], dev->vhost_id, strlen(dev->vhost_id)) == 
>>0) {
>>+return i;
>>+}
>>+}
>>+return -1;
>>+}
>>+
>>+/* Inserts vhost_id at the first free position in the vhost_ids array.
>>+ */
>>+static void
>>+netdev_dpdk_push_vhost_id(struct netdev_dpdk *dev) {
>>+ovs_mutex_lock(_mutex);
>>+if (netdev_dpdk_lookup_vhost_id(dev) < 0) {
>>+if (vhost_counter < VHOST_IDS_MAX_LEN) {
>>+strncpy(vhost_ids[vhost_counter++], dev->vhost_id,
>>+strlen(dev->vhost_id));
>>+} else {
>>+VLOG_WARN("Could not assign ifindex to \"%s\" port. "
>>+  "List of vhost IDs list is full.",
>>+  dev->vhost_id);
>>+}
>>+}
>>+ovs_mutex_unlock(_mutex);
>>+}
>>+
>> static int
>> netdev_dpdk_vhost_user_construct(struct netdev *netdev)  { @@ -825,6
>>+882,8 @@ netdev_dpdk_vhost_user_construct(struct netdev *netdev)
>> err = vhost_construct_helper(netdev);
>> }
>>
>>+netdev_dpdk_push_vhost_id(dev);
>>+
>> ovs_mutex_unlock(_mutex);
>> return err;
>> }
>>@@ -1773,9 +1832,18 @@ netdev_dpdk_get_ifindex(const struct netdev
>>*netdev)  {
>> struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
>> int ifindex;
>>+int ret;
>>
>> ovs_mutex_lock(>mutex);
>>-ifindex = dev->port_id;
>>+if (dev->type == DPDK_DEV_ETH) {
>>+ifindex = DPDK_PORT_ID_TO_IFINDEX(dev->port_id);
>>+} else {
>
>
>This 'else' statement is executed in both the case of vhost user devices and 
>also vhost cuse
>devices.
>In the latter case, do the port numbers returned by VHOST_ID_IFINDEX make 
>sense? (i.e. can
>sFlow 'talk' to vhost-cuse ports? If not, then this code has a bug).
>
>[PL] At this point for vhost cuse there's always '-1' returned from lookup 
>function, so in
>the nested if statement you'll always hit 'else' and 0 will be returned as 
>ifindex for vhost
>cuse devices.

Agreed. But then all vhost-cuse devices share index of 0 - this is surely 
problematic?

>Anyway 

Re: [ovs-dev] fixed asset

[Reba Patel]

hello dev,

 

You may refer to the attached document for details.

 

Regards,

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

[ovs-dev] Returned mail: Data format error

[The Post Office]

The original message was received at Wed, 11 May 2016 14:40:18 +0530 from 
openvswitch.org [195.249.234.156]

- The following addresses had permanent fatal errors -


- Transcript of the session follows -
... while talking to openvswitch.org.:
554 ... Mail quota exceeded
554 ... Service unavailable

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

[ovs-dev] Returned mail: Data format error

[comments]

Message could not be delivered

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

[ovs-dev] [PATCH] ofproto-dpif-xlate: fix for group liveness propagation

[László Sürü]

Hi,

According to OpenFlow v1.3.5 specification a group is considered live, if it 
has at least one live bucket in it.
(6.5 Group Table Modification Messages: ". A group is considered live if a 
least one of its buckets is live.")

However, OVS 2.5 implementation incorrectly returns back group liveness when a 
live bucket found in
group_is_alive() function of ofproto-dpif-xlate.c.

Instead it should return true only if a live bucket is found (that is != NULL).

Signed-off-by: László Sűrű 
Co-authored-by: Jan Scheurich 
Signed-off-by: Jan Scheurich 

---

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 2321802..4ffd8ac 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -1502,7 +1502,7 @@ group_is_alive(const struct xlate_ctx *ctx, uint32_t 
group_id, int depth)

 bucket = group_first_live_bucket(ctx, group, depth);
 group_dpif_unref(group);
-return bucket == NULL;
+return bucket != NULL;
 }

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

Re: [ovs-dev] [PATCH v2] acinclude.m4: Fix skb_get_hash function detection

[Markos Chandras]

On 05/11/2016 02:41 AM, Jesse Gross wrote:
> On Tue, May 10, 2016 at 1:21 AM, Markos Chandras  wrote:
>> Commit e2f3178f0582 ("datapath: Add support for kernel 3.14.") added
>> support for 3.14 kernels and a new OVS_GREP_IFELSE check for the
>> "skg_get_hash" function in the process. "skb_get_hash" was introduced
>> in the Linux kernel commit 3958afa1b272 ("net: Change skb_get_rxhash to
>> skb_get_hash") which exists in >=3.14 but the OVS_GREP_IFELSE macro
>> also matches the "skb_get_hash_raw" function which exists in older
>> kernels. As a result of which, the check makes the build system
>> behave as if the "skb_get_hash" function is available in these older
>> kernels leading to build failures. We fix this by explicitly checking
>> for "skb_get_hash(" which matches the function definition.
>>
>> Signed-off-by: Markos Chandras 
> 
> It looks like skb_get_hash_raw() was introduced upstream in 3.14 as
> well. Are there distribution kernels that you are referring to that
> have backported one but not the other?
> 
Hi Jesse,

You are right. SUSE has backported that commit to the SLE12 kernel which
is 3.12.

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev