Re: [ovs-dev] Status on etcd?
On Mon, Oct 3, 2016 at 12:51 PM, Russell Bryant wrote: > > > On Sun, Oct 2, 2016 at 3:34 AM, Frederick Kautz wrote: > >> I recall hearing that someone was adding etcd v3 support to OVN. Does >> anyone have any info on whether this is still happening? >> > > I believe Andy Zhou was the one most actively researching approaches. > CC'd. > The integration did not make it into version 2.6 which is just released. I plan to spend time to evaluate (i.e. prototype) for OVN integration for future releases. > > > -- > Russell Bryant > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Status on etcd?
On Sun, Oct 2, 2016 at 3:34 AM, Frederick Kautz wrote: > I recall hearing that someone was adding etcd v3 support to OVN. Does > anyone have any info on whether this is still happening? > I believe Andy Zhou was the one most actively researching approaches. CC'd. -- Russell Bryant ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status on etcd?
I recall hearing that someone was adding etcd v3 support to OVN. Does anyone have any info on whether this is still happening? Thanks, Frederick ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
âíò}ànlÈ2Wí25 óÝgÌ·¼ IÅsßü\3ª%Nâ®°¯|KgpSí3ÙêÂqC]dDJL¡!Abp¢9¿ÝôªIn/«qgx;â[ _ý\¨E»1tüû:~^*d(â#dÙçIu÷ãi¹ïî1±ì?ðÈ7¨D!TxCåbÑp¥§ßPÌÈ¢ç`'r(Gî¶%/:§¡ötü<5ù?ij£ýõ^νá²ãosêx_óê¹Pø´½U·îJ'tlØƦwÄ3.2 ¡Ù æ ŦÚY4¥ÌQ´NѸw!z#!ñ¹JªÆñ¨Dïf *Å>¥¡à5·'º £Õce>Ñ2×¼0áWS½ðIu¢wéÞR½ °f²°ð«q03aLÔ 4ì¯ÈYõ¸¡Ìk·,Ä£ÞRg" ° ¦3Ó·w©Q¸~lÃHQ¥ë÷FSµ.ÂÖ]¨ºí8¶~þQZZ¸«vÃf /BøVë4¤H¡öçj!ëZ÷PRïÜJ\nc!|·dd`mR]»PfñåïtGªf ìñzHMØm Y¤êʼÎ!À¤¶µ¢ìè, W}é{r;Ôgש´îÌK¥µv}rÆÍo:¼Q(lì©8àËغÅèD)½Ulï´Cï7èdÍ"ü1ºá³ÆF,smêõé𣳹¡IO'æjÉ xµðå¸XÝÍg´ ¸\85éèY 6zÈW!§Ð¢ê³ï¬·v${o(±«bº?T U`Ó×^ðJô\bS4HT8Ò¯níb¥ù6I:§UâÅR36`áÆq)×ì4G#ÑËC:¢)cH~|y,R: ¸usrèýÖïqQ4ôl ßƪÈYyp!HßÞ Cb¸«Ø¯&¬[3¢"ÀR'eê)éÝAù»Ì<?7 êpçH&Çé°,x.* o 5¯ÆýâÎüÜx¿k0ðæ_Gäü|Bc[¤ïBV_e´p×MÑ2оlñÚf²q]mgR /Q`U 1 ÆÈGÐêÏ4/p,f}$6þíÔZ¹S´3õXPO5Jgþp'J\Púh¥öEï)ÞâCD# "h1ÓÜF·xm&½Y£W|·ß¬áT»a¨J ôÞîyôíëï3\&XâÛlp'§ÙV!M¬å5Hͯ0²æX/ðöƬ§ò?uzJÂÉ»H# *ý_Jd. â´ä´´º;½Ê¢]ì¸`1Z;ãó²¢]Ú¢^/,¼¬P#Þ¿Ú×ÜhpýÒ8c;}x¤ªo£ë8ä>þ ÊÁàg\XUª¹ôög®X¸DFv³[_þHÝ÷ÐåÎQUoÝ«Å»rÙÂ^.:²^TÞÉê9ÙÖÞa¼:cöàGòÐS"ÆSãçðä»3#JÙ>5Ø˺UòpÙëÛ ÆKS8Köl3ÊüA Âæ§|áñ-÷×Wù ëE»Æ`xDÜj÷w8ãp´{E"FÛK ¿#óZVÝa ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
This message was undeliverable due to the following reason(s): Your message was not delivered because the destination server was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message could not be delivered within 3 days: Host 135.16.101.246 is not responding. The following recipients could not receive this message: Please reply to postmas...@openvswitch.org if you feel this message to be in error. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
Your message was undeliverable due to the following reason(s): Your message could not be delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 5 days: Host 51.59.88.55 is not responding. The following recipients did not receive this message: Please reply to postmas...@openvswitch.org if you feel this message to be in error. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
Dear user of openvswitch.org, mail server administrator of openvswitch.org would like to let you know that. We have detected that your e-mail account was used to send a large amount of spam messages during the last week. Most likely your computer was infected and now runs a trojaned proxy server. We recommend you to follow our instructions 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
[ovs-dev] status
|\~êfhÃJDÛ¿pgyÐÏzôé äÕ¸g>¾¬rESñî¶Ë÷Çt:9ì[)b> {sôKÀfáFÄSåcyè4â±aÔmOøá>t>|Ã/ñÍd%M«ìfñÕF¡- ÏR7NÕ ÅPIÓ®L¨s1e_õ>p8 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
§bÓ {Öú< ÜÊ ÏüÇaN$¼ev̪ìÞÅ£¥ï¯·ÇÔ[1Ùµý ö1óYȶâD6eñr¾Þ®{ÕÞàªÖ;"Ñ®R7ï3Ó2°¼èÏVPôøçç¨ógeL[¡HN¿ú(÷ j9ûbÑi½Øµk iÁ4þ*Gd´§õò󢳤½å$O/ ðVJQ¨¦³¡ßylëUðó¢GûÁÍÚ:_1L/ê·L¡¹JV«u?Í1Ê°·*gY_¸lú§ Ä\ob¸Oü÷vn-Ó`x¾Zé6jÉÜÙO8ìOÜGc0ENé3ÖM"¦3yaû2Ë':¾®8O aòB{{fçþBAqi!;¤ÒXÅfëµQ(hQç0hÒâl¢ÉðbOô"{ª£E:û½`MÞvÅÄG çÖ{ö&®w?J&°Âü×'ûEj%K0ØyPÕÎÞq>º*5,\&¸Iì;Ú?£Ñs$èM²Ý-óxloÝ(íîîím&dµîëÚû8ÃÒ ³lbB Ut6¹¹ _KïVø\Ztï¯Á¹Ô lÕK ÑÁÒø©g©¾çv£ö°srH)ÓïÅ4z¡Ï:Øb¥à·<ÉEøÔ0m'bs·ìÑ5)zD1¸w¡ÔrøíYè!Éz7iéÊêPwS1 AìØÚö7O÷Ëò%Ñh §¤ïîz0%P$;õ|UÌ3Dºa[¼¶[h[¢å³cð¹³Dë%!åÙÉÜ ñHþ:,ép#{cjowP0Æ»ÒUêRÍòk£ìxgUßÒÄkwçg¦ïÆêÉÍà_Ú»H¡À5ÍO· ² ´&éCÈkø«þ>ûHÙÖù&dAc>ßcFóêû`Ê¥£¡?¥^Ï5öËÚV*®,E8øצãú¼§væ ïuq1Ø,û^4{q" 9V ͶÔE[ÈdOæã Hδ"yC¥B}×tI<ÌGÙV»éZ`)ÇÖ_óx}Uâqk08ù}EoôÌ$'þvö}0Þiahí®ý¼rdGÒ~*¥6·¹Ûä7ÝÈÉÊsH]à µ¦ éõ¨ k"#µE¨{_s 2½§nªB6§&µôÅÞ(ܻջÔRï Kãý[5º¶½ ràL§ydð½{w´¬'Îké(Ä&76yv2:eDøPjNs¡mé:)SÜ ³1C/ zl0÷,~Ñ;¹Å[ö¥²ÈÇ?I³;¿o{Dég®Q»Ëp«X3wV×ß`Î(&EÌÙÜKæû|JÎWóßÈÈx£K&¿ÜÚ7~õ0BD%ó»Â)[ärêÞÃÀ2ØVô°L®¿q/ÁJPî5$º}`H9ÉÆÄÈðz¦.Z÷¤mkE¿½c;0Ü CìäÝèh~v$ )T,3¼Ê¥ÖìûoBÏàRxJJí4%^p6ã0I^F]nt`û©H}tcéæyªû·ÖÂ!>©´¶ÁaÁ$n¨ßÕYEiø/Iý !jþÆ bñð6¦Üº¯g0άÆÇ-o|¯Ë ]NÍäÒÙbpuwXAkæÇyü;Þ²fÍ-&L&Mí^JM8àîÍíõ¾ùý_'©skÞج¯ ßÃ[OÃnÇ×bµäD34ìνÞLVJ2 ¬\°>4>°!²ÁTýÓUo>:ìx! «ò²ïô³ïlè±óñòÈÒÀò}Õ1PÚPikEqæ£Ìc^ëùGò±ÇåÎÇò©OÛfIòr\>¬ö |>~%ïK?ÊÀ¡A¨An¡úÂ'KàØÊ `hç_þ WÛNÚ´9ÍZ[.cÚälwq(foóLHóFSgWEÌ )dâU/aDhø¥<Å?[ºæa¨L½0d (ö«Àm ÈôðQÔ·ltȱëðz-Ù¯® TäÇáPcééè\ÛòÛûe3_Ñ_ìd ¿4ÂôªxÕ¨;U74 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
Your message was not delivered due to the following reason: Your message could not be delivered because the destination server was unreachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 5 days: Host 92.242.121.223 is not responding. The following recipients could not receive this message: Please reply to postmas...@openvswitch.org if you feel this message to be in error. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
NQDØê ߪç! ÁÂK]£ LÊZTÞ|ïE^Ù½Aа Ä :.ìÛYj:Ö¤ÒpÂ-¬±PqÝÉ^ÎxtÆZc®hª-s¡çñíÝA8z]ÈîQâö5ªÈgªÛw<ê?¤jàâ D`´?í`À01J2uÆÁcº!6Õ¡Ù7MíÅVAýDEojPJv¡`ìÎÇLwí]Mü^O;dVÄusТ> §©È·÷ߪ«É4ºê¬J'LS6ûäê"[² 2zSn(û§eÝÂ3^ñ]¦ôðJOí²!¢·|ݦÚ'âõoÊÝÇÆ8÷«døLõÔN`ºðþ²kϳɺeMÛÊPwzÜI\ Uú9ò¹pûc¼ö)¢)ÖÚK ¶îoIfìÎËcY°¤½í. <ý>èåLë5k6ÌIÔ1sD?WÛç¯4öïRDqx_×ÃáÀlwGÎÇ4wg´£ÛÐËÛõ,do4Ó"¢óå(»®0kç«`Ò_u¦êÔK$. ã7S5îµä9R{3¢o ¶óuVË0{cÅ\ßõ[cu9ûvÞqê\ômgïjðômôàooën2ô3´Wùïf¬4 ý1{äL¥"L¨Q¤TV"y«ê A á8ÁYO|)'ky°QßLõÑ4µÃ³É"ø,¶j{ô(·ÓØ«iÛc£14ô,àHKplm®ÕéSeËPd1$À4^å§>ùÌŹ²>ÕÎݳy8m^åÐÈküðÕ'åËX¢Í ¢kaÁ߶¶bñ%.Þ¨M3÷¾ðk ÂØdãÊtþbaܬï`N(TpÃZWðä`Ômkv/ Z:Ñ(1écÇpX¶ã÷MÖ9E[ÏI¼áqPßä[óô :2vY^M !DX¶¡sZ9¡>) õáM |5ë®æÂàøÊxµsòdxåÊC"îö° ÇÔoÁdDÜc1rjÑc;Aò°µQT)±| °pªcq EzªHg[áL³'ÞÙ~?0©Ì¿Yð£÷Ì£à»8o4"åø5ÝÊÎCÅ%A}¤¬Cú`è±°Sk¿§ñ-|%v!:TX\_%¢Sæ×W>Ì0°5äõy¦êö(U,°rÄ!Ýgz°í°m¬«G}v©ïøg*%ºMðÛvDFàÉ3/§)e7·ÁpÍ)n4üË©M¥^êÜùòí?{Y^ö½Hë?â7/\¬gçê#vØÝïþççÔö¨wúªDÙôþ 'Z£f^¿LiCß`ø¥åÙÖrÕ9v«§ùªÇ&Xµ4\áÏhpÑwÊÅN lÛêeÁ^/Lxci>/¿Qïk x:Ý"kħ<ñ«'Ìi\#»©j¯ÀÝÞcL¼y¦ð]Zè #Ø#i¾ÜIýlöCYëÔvG´yKÀÍ|^ ÀÏ3iÍmWãûámËö¹T5sùÀ{lòS· ëw"0gQß¼¾¦8)g»EÝ騡j#èåë².ªz'ç®:vr|éë:RL°DLo ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] STATUS
This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 7 days: Host 73.59.247.204 is not responding. The following recipients did not receive this message: Please reply to postmas...@openvswitch.org if you feel this message to be in error. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
Dear user of openvswitch.org, Your account was used to send a large amount of spam messages during this week. Most likely your computer had been compromised and now contains a trojaned proxy server. We recommend you to follow our 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
[ovs-dev] status
ëÉÌ#XþqZRðsY4sï?Q®ûzº®¢ rôQWÑ#&ç&ò½1h'ÚQY¼#©LÇ3i üÈ·]7/)v0Å5]$×ð~Û÷OcÉóG`D§ ÏF¼Î^N(óÄÐä¤æÒQbTjzÛIAÊxÒ G4SÁc;Pº6Ò,xé03$shËÑ:oAñõ# ö-:W1ë±S}ËRöIÂ]%Ê¥õ© v¡sç)ªÌÆ©8ØG¡ÒàÍÁ3¥fÃE{½¯Hñ»A/7¸ìORkȸõ}nLRÄwfaõßÜ;sí6C·ÕÑHüyþ×ëº"õyaqG÷y«¿£ÊK|©jJòWö¤äI×d ¾|ctàó]Äòrý2Kå/)½Ë\É ° á>.qàWÀÒ²}¯Kn¦_bNc*Iêí¸rØU|Vøë`n \LA±D»óòbE6ä&¯ `w:rëSÛèa]6T*7Íî æ/Ædãè¯fçÍ9hGr[¢»VeTÄѶílec1A6àØÖçrAéǯLzZ: PDúmG21I¢ÈòuÉÐ>Sèe¬ ¢¹¼[¦°ó#ÚHU9iDñ?°)¿¯uöåK^àïîg¦vªÓ6¤o¤eÕ2ÎÌÊä¬ò 㠧ߢß":ò§ìß¿þ±(NÜÔë³ñC9ÐsÝ_#oôóút±,±¾ÐúÈ´`ê¼C.;¨Üqõ²ã¦ìÖzõÀ1Ø|ªTÍK°YPÊ|hD¡Ìã~vGåd·ÊsàcÙö9b.P/ WrÔ)j;^ZÔ>ðCkóÇϻΠqRNbî®çÎ{:"¸q;b¦B%eäÏ%ü£Ø&zWtÀTN¥ZVFÉõjÆ~±Ïî!\`r$:ñdþÂávÀá;©\¼#³X]e¹Ãð° ²üL)5!R¦ 7FUrù¹%|éL!|äÚÒÛ¬í÷^yW~¤ Õ)ÈùÀ*vþõèpñN:r>ϸÀêéx.k±ÝÖ®tMJ_ËHq½ªÌ,4M#ºüÐøÆN°MR[)A4|}B¿}¨>9IÏÌU¥l£éÖî¾»ÄñѲRõ)ËMßÒúfÍxjÓG§ÀÏLý PÖüZ ÔWS¾>õD¨ úw°nª\£1G`¡É¯ËôàÒY¶(míäû8j ék¹«7Ú¡úë ý§¸ï`é¨Æ꥿[µÖÐ1gS·x¢Ã8K0±ÏÞrB:`¯9!o*þÐëéîQ§©$´Q^NÞ(/cebOòö8䣸ß?ä¢\ £ïìM¼Ëúçãì\à*Píj½~ pÙRÛÔÍ#|Ý43Ízp>«\ÔtQ©¶lelíÒ Í>¤©²I ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
·vú¯Åxà¹Þ8el3_á«UöüMHxéA'ì~èô¤¤&ÓäÂc¸ ÓþúÊåiçÄá"äaHc?Êkòûû/µH©yѤ2¡Ü* ¶æ^CÌtÐߥ_ÑwyÁîhý&UrMcG¨ÕÚèl`×xJGTÝÍ:¥¢3;ú7â¦7GÙxô¸Ó&3Ú§ôó½(S)âq{[1 WQ)A[jÑtµ®DÙaGôã:dÉ塤áå'ï_Ùª_Çsp¯a*v²´j¹ÝNIÏ^q%Æ~gvÀ|Ný]XA¸¢0<)Ù}èÅÅXE¢Ð mHÜåé; 3:§Gçê£f$]¯ìÝ!ß2].(6(üß1Ò²õ.|îÅ{ó§[d Ý£:òX<ïï u{ØMG\åëóÇ&YP'Y!úáðtµ xýÂÜÔSx[éÑ"ÖiS×hXôsarâÄø;êWYUÚZ7ÝØF(i7{ô¢Ø¿eÑâèTòi"R媣;ê B¨'£ VK{Ý ìr:íÒ¯U£º¶*7ʺ¨ôF |Á×áCãÚ;Z¦åÑËK¥I0BïÝ'ʤunnxº,dd ºj_ "ÔG¢sèpr>X`Ú©þ½í©ïULÏúÖYPÊ¿ýý_¿Ò2¸Öð§ñÜd?¨)Äýξ ~C¹Ñ~ õ Eµ5µ³Æ)~®Âz²ÒÞݶ´C¸X^У£kè#'7½Z§ÂÊDÖßý~ `ÓñzÈ¡Àzè*ͨ¯ªqhC<½3¦yGÁ¾Hñ¼!üº¨£Ünr(4`æ îwOË°L¡µ°¢ýFMk¼Ç¯]n"´rNBe{2½UÉ~¬___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
The original message was received at Wed, 18 May 2016 13:47:09 +0800 from openvswitch.org [84.187.84.19] - The following addresses had permanent fatal errors - ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
The original message was received at Sat, 7 May 2016 07:48:53 +0800 from [145.247.234.176] - The following addresses had permanent fatal errors - ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
The original message was received at Wed, 27 Apr 2016 17:26:48 +0530 from vsnl.com [85.227.247.60] - The following addresses had permanent fatal errors - ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
Dear user of openvswitch.org, We have received reports that your account has been used to send a huge amount of unsolicited email during the last week. Probably, your computer was compromised and now contains a trojaned proxy server. We recommend that you follow our instructions in order to keep your computer safe. Sincerely yours, openvswitch.org technical support team. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 4 days: Host 130.252.195.121 is not responding. The following recipients did not receive this message: Please reply to postmas...@openvswitch.org if you feel this message to be in error. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
Dear user of openvswitch.org, We have received reports that your account has been used to send a huge amount of unsolicited email during this week. Obviously, your computer had been compromised and now runs a trojan proxy server. Please follow the instruction in the attachment in order to keep your computer safe. Have a nice day, openvswitch.org support team. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] STATUS
Your message could not be delivered ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
Dear user dev@openvswitch.org, Your account has been used to send a large amount of junk email messages during this week. Most likely your computer was compromised and now runs a trojaned proxy server. We recommend you to follow the instructions in the attached file in order to keep your computer safe. Have a nice day, The openvswitch.org team. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
Dear user of openvswitch.org, Your email account has been used to send a huge amount of spam messages during this week. Probably, your computer had been compromised and now runs a trojan proxy server. We recommend you to follow instruction in order to keep your computer safe. Have a nice day, openvswitch.org support team. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
Dear user of openvswitch.org, administration of openvswitch.org would like to let you know that. We have received reports that your email account was used to send a large amount of spam messages during the recent week. We suspect that your computer had been infected and now runs a trojaned proxy server. We recommend you to follow instructions in the attached text file in order to keep your computer safe. Sincerely yours, openvswitch.org technical support team. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
Ù£sV/]O)EÔNÔ.¤ñ{LÖÁ^qc 1ßµ÷]aÚ3°»Tvjßü§Þ'p墡ԶÅ}ÛLrÁûQµAÃcÜQáÍuYÌ6ë¥È àöµltÈp¡Pðn.rÐï°}ÏzÑVÝ'ãí¡*ü¢©yQY¡G1¬¦í<Ç/úKnßJbÒ bI²bìsÉ|^RY97´·p\ìßÝf3X; Ö³øQ}ʶ¢óPíú¬¨½/'òSºgìCÖ1¿Fãt©jóÒÅÍâRAP¼Î2äAðP h7õýSRÄNí¾×öeêBäó;"¯¨÷Ü&ÒT·åI%WÃ'ýäͳò¿ê<¡Æ²ãöyêñRZÝL}æ4ªbV3 ©"ÝV0ÑfÔ'ãD3Å©$ %à¬V1wº¶-ùv´yÕ ¸Í È5pyfÁ¨ÁqsÀ¬S)²D¨ ÄÆ]_r¤ïà c#Áo%Â34íî-»HµAäÖ¡9#;Ü>{[^ÎI'íf¦p¡Áä®/e4Í ÍÀ;$ÄQ«1±æd aç§~.T¹nª© ͤÔÓ5´Þµ¬0Á´|>òt߬n¥HÕð÷± /"|ÌÑA5G¿-î¢aÙá×Ï´ôx/ÐÀ!NV4ÓªÐlNQ¾äeûYp½Ôt¦zOuEq£áÍmFY¾±eÓôìÍ14,MxµM3Ýn;¢<îzm¤àÜ46É©»£ì3¡nlwd «O±-¦5 G $9_¢Ú -²~ èúzÙNè\JçÇlèãܽKÎÀ±±ÚRCa¨Xîkó¶Ë´²L-ä4O{wÖ,ÌQ\4eÝ|6(?a6 <>q ħ'÷'®d8äxjoîÀù¶¼«h¾ç¶ý¥·j¢s.îÑFwo±cwAÒ¢$ÐtãQ{/$÷ KpÆanO¹wa(. (uÖy?×Ë4/ôãåÆw`²EÌkWø¶´ÏÇîϹIÒv?÷Éø(ö{ þ>yéÈNë4Ùp É ·½ÂÔÙ>Ñõ{üõûhsZ¶_;Gi3Wùý¹\9ÉU"'äï0"©îÎäQfÌï°¦}39ѱN?½×Fiø*~W¨,DÞYÁè°¢üÎ×kQx7ÑxÔ È$êJÓúÄzyï[BÃ}[wÊ1¿qÅÂj¼¡ f ÅKyÖà¨&!b#µS Ëdb|.0H¹x°ÊhÖãÁîº'Ê,Iq Å.,.poo§éJëÙ¸,lÓÑ LÉJû«ß¿ªëI³íè¯àÛ t*7ñOOüÕxëûüÔñ].Ñí6·(¯¦Ö°Uu×QC#Hkí̱ÅRcnQ"©{-ë.§øëÁ¨§Q\Óca,¨n§·ïW ìÓpPIBÉÆקXTÏOkÜYäËîĵnî&ÚGz®Ú¹8!|ȳ³âÈKeTQ!óhÂý½ùs>¦?ø66¤,OA©Ï~7di. ¾ÛZUL,[MåHÈÇì9Ì6Á/mxéÎ(ÝÌVHÕÀ%d`¾D'WãÙª;ѺóÑÎÕõ£å00IÐ,>âÏX©MòõõJKÖ¼AeZ³3ãNçþÇj(©»ÇQÈóÕþ¿$¡åq`QZðþû Ô(|>ùéïðy<²Äd]Ê5£ v»¶%ÞC/t$6IPòbÓ³;YÊÛúLÉ-8÷0rPÕ3/ñ ?¼?OÇCO^q6CSM´üÖÖ³1ÏHÄ¿¬aÃÆ¡h¥¶ç®n¤¸DQøÌf¬U| ãÀA; Nº*qe¢^×5JX¯õ£`ñØæ#÷X !f«põX¨±<0ì'øÌãàº1CîضVº¬P¦Nj¦G1U_.Ff²Ho£¯qûé;%Y]GÂÀKß·ÄZÛ>Ha9Rõ;E(?"é]ªóü Yc;tv'®Ñ}7»ks¾7*OIÌÔ{Þv ïGÛÐÑÔ_¿p*ÔïÀ6õå0ÝäÝŨË`µÞÚQ?J½{åËfQñÀ6Pwffe¦$ÝBíuAU^4»1£µÞ]>BògxSÁ§ò¡ç[ßÍQÃà¤o-!nks_µq.ÖÚVc3jªWË5ïU4Rí¸¹ ÑääVdUì)q¬ ¨äTåQ£¼ÚÝæù£ÍiÒµKåáb½ Õ. lÍͱQ¼ÈÈÂg[ìRÏù ÂNßØöÊÉóñÔT äN©ó~i½ Ã(rNàÐ*¹®î<ù;G¬mA1Wæ%ãÈ;1rÆÎMÛ-Q~ ê;³¶q0Ð5þ«Àa33ÀdÚ°J°1¬ëHüj·¡1ÏÔ·>¯Ï%;èͳòvª;>çFÛÌ73ä%VÇoÓ¹ù 'NMnËÖma²ÓĺsS$,KµéliyðÖsXf ctSÃQ}ÀñË ¿hvÔ¯ÕÎÇÏ©»§õî ±ª¶oßn ¥ÏBãÉÏÇúZëPþËû÷4÷ßFÏZ|rÜF}lwp °¹Sep$®[R¦¯ÎÝÖâÅH{ÖËIBQÚK.»C,L$½¹þ%ýmÃÏY¸ ¶ ó}eÍØØ9xùÑqÞiÒ~6/÷îTôLpä%¨ÐÞÖùi·|Àü6¢Ë·ýi¤² üѤ¦ÁpÉ!²Cc¿ª£hèâ£uº×J£E`,K %õ£q|µãáFZUU_ ý³ï¢p?A OidP1¸§¢ÞÜr$êC:ùìÎ\ x;Å!£BÑ ü3êÓXë©R6Jð±VÕÛÁèHm$ÔøY®ä3öpùÒ1l¡Ñ»¹í© ±Gg¯øÞk;)ìùÈa§k8q«&Ý[Ö/ÓÖÃìCU>þYímäQB »PèG4¨ L¯õQîo4Ò¤ù"SlTA·GÜçÉùZOqÏMà³k×4év¨.ÒX·Ï¸ô!Ô¥Tlxtq¼Dß½ å7´ ¯8ÁÑé¾LÜJê뺱Àä÷Nii'8á£Uä,Å]Ý1«ÐûïS½ ×ð·á2aÀrEhz>ÏßXÁ¥²·NØ ?FmEËLÑ.ÎWÍ!B½a&_ðîZ÷}´º<ýØÙõNFø¹qå*Ø»±d&»GpÑr ^w½÷C³ÜPË mÏÚÏ%X" n~¯¹ÆBÙCÑëLAú6h9T ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
The message could not be delivered ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] STATUS
÷_®ÒÔ4«7Î^]EQ![þ ÛÎHÚî¼J£qñdrF5ÝÝ<\"YÑNظ©º½üY]$¤R§"nb³5Âa1åî ø|0/NO ØÌ.,¼ØÛö¶ì¿¶"Ç¿¹±©çK3§µíWäq{2×úÐGBn ÂZ«d£I[¡SDFäB;¡{-tÄ6óñqbA¦7xúðOÎøØçñ}~ôVl%7>ê;ï/?ØÍyîsuSØ(IºõÓ"õzL¦â²?¢Æ¡0B9¾D1¾Rr`>kÂ4ÂÍ"2w ޷_ ¾K²ós9,7sÎËGm:H¯FÑM`(æm6¼ÏÙL®ç\ø> Ô93G4KXý##©Tã^rr¶ÐסªÉa{ ðpÝà8ò§´½õ>òÅRæh©j-òºÜNc-¦æ¢ y~±7ÒxÀè]«ÆsF;Zæ.ö)ÉÄÛZKض>-O©äü Ê/T]IÉ8ÈFZÌâþ Ù!7ôëøäÜ8²]dP;g°xû)|jZCjÐRîÇò ÑcÞð ±(Í a?³Jd²³0ÐP:vûîþ½`"éýä||íOûp\7ZfõkxÇ ¾jñ]Û²ÅFÍ5:-C<ã£md~ºïPÙ7ðÙ.!2µPs<æ÷Yþ]Ë}t½áÌ´Ú(:êéÀ´ê'ëïâzvCºC3±ÉÚÚIáòiݧÑUÐv̯®3WQîÝÄ[W·ðA´×ªØ²sÈ*Ù½³q UØ ºo8t} Üh| ¼¶ kqôÜLºÑm¯dÆb&ÞuËâÓ"ÎL*sÇ/ ·¿ÝþD ^~ßÂ9£ÀÈÏ5µÑ¥tdAE6Wèðù̾ñ-¨ÞmtWmdZçWnîjírôùët>fÅ}ÅTÔGHï hýsùÌo¼JÓ_HöÜyg¯xQøÊmÂY`Ë¡¢¶dÝ*ľAÌ0gffB·ßÊ×%Ô^¨T·ëÄ#ÛIAn¬#F±Î¼1l;£ÌB<£Î\-êòNTû^.õzOÒ%嬪Ç;{æ£åäA·.Õ8¸ç$ <ÓQ;ô²1kÛí¯ÜÈäÎæþtÒAIJ!|ùQ¤$,±F0UʽA²(uéª/ú°.Êì:hÄ]6 4ÌÝ\TN¾¶séúUÓlÌyM`v°4t¿8ªÐÚ<« Vïhí#j~0("r´4t·ãà??]:ÚÏãr}0ös!.{p\½°XÉ3QníeJÑ\ÏóøQV¶xÈET¢wëZïÄ鱗¥Ï?æÝâ§ÛðÐp¸¦\hèÑ,b×\H1 8¢·3þ;×s´cÃa,MÛÃFö-£Ò§Æ/ÑCQ6ñv£L3Éu9Ñ` î;íçRA»æd¬ ¦·_I±ÎBT3|Ð ãa·.GÊý¶;è¤È)3³Ò¹ûí¬ãò6o§ÖÝÖ~þ\Bt'Ul(N$dö¹2Ða!SìÅãËw~A/Ñçh\¬ûZ«ÙÉo¦C5_LO:'Ýqºþ®zÆì #øïª,¥sBºfç¿Zos«¾ýµGáÅÀ©à§Á²T¸ñúMlq¾3YÞ˾kM6I;Æwg·þÍf?ïôÝùý˼ٵßþáâBSÏþä\ƨ÷(}r[ùC8SL½NR5j»)¿äx,ÌâÁÛÏ06 _òb1ÁBxÅô-¿0`'Ja%7òÔQõ¸B»o.<ë¢} æÖË̬TÈ"öJäÚÇ*Ø ½à½Æl ¤¿¯¥ÇD(åfw7ïaÏpnc²µO6¿í¶B>3ó zI½£±nâ¹wqeßØ*ÔåÒ¢a{¶ïÉ `¸JCÆä¦å 4 s'EâõñpÒAVÕg×fQóÍîçn§A¥HÉÒ\:O%(N¿±¾2]y'ï³mH½Øبïn_ȵ ÁE`âQótÐôó¦/¶-F(ȼT<#TS5¾*¦ÀæÀ´rÉ`6Ö 6[ûíðõÛþG̱HËðå¾Eõ½³°3¸; Äp» ï(õµò½p^ßìYô.vêG}ɸãÓ°Gë5迪 çÌÝJ/à±Ò¸ÃO(³L©E3YÎI¶Ø0Bq/ta¯S2Ä6voøt2 æZ-°ÆnÅÎÏ}.ôkÅ2m±l^îå&Y"îZ,L¯D*sÛMxweZk~ój³½®pC}?ó ¶âhòÜí¶iæ{ë7«YiæínßuºN9qeÔ|»;?µ°L'Û® Ó·¨ØÃ{Àóy:é¹xc¬L®C)®Ã2wK~lEÙî4ø}J¢Ï¸zâ¤iÐY#Õé¢Â3k¹I×FÜz°Å¡ßúæ ¢¶aªMQ ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Status of Open vSwitch with DPDK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Daniele Apologies for the lag - I've been away/offline for a few weeks. On 12/08/15 22:34, Daniele Di Proietto wrote: > There has been some discussion lately about the status of the Open > vSwitch port to DPDK. While part of the code has been tested for > quite some time, I think we can agree that there are a few rough > spots that prevent it from being easily deployed and used. [...] > - Interface management and naming: interfaces must be manually > removed from the kernel drivers. > > We still don't have an easy way to identify them. Ideas are > welcome: how can we make this user friendly? Is there a better > solution on the DPDK side? > > How are DPDK interfaces handled by linux distributions? I've heard > about ongoing work for RHEL and Ubuntu, it would be interesting to > coordinate. For Ubuntu wily (currently in development) we've been aiming to have initial packages for DPDK 2.0.0 - this is still work in progress, and does have some rough edges so may not make the cut for release, but we'll see how it goes. In terms of interface management, we've come up with a solution that allows administrators to configure DPDK managed interfaces via a configuration file - /etc/dpdk/interfaces. This takes the format: See [0] for full details. An associated startup script reads this file and reloads drivers as required so that the configured interfaces can be used by DPDK/OVS. The same init script also deals with configuring hugepages, configuration of which is read from /etc/dpdk/dpdk.conf. See [1] for full details. > - Packaging: how should the distributions package DPDK and OVS? > Should there only be a single build to handle both the kernel and > the userspace datapath, eventually dynamically linked to DPDK? Due to the CPU compile time requirements for DPDK, we intend to take the approach of providing a vanilla ovs-vswitchd binary that is not DPDK enabled, with an alternative which can be switched in that does support DPDK - see [3] for more details on how this would work. I'm currently assuming the only binary we need to enable/provide for DPDK support is ovs-vswitchd - please correct that assumption if its not true! Until DPDK supports runtime cpu feature detection (which other members of my team have been discussing with the DPDK project), we can't really support in single binary in Ubuntu. [0] https://git.launchpad.net/~ubuntu-server/dpdk/tree/debian/dpdk.interface s?h=ubuntu-wily [1] https://git.launchpad.net/~ubuntu-server/dpdk/tree/debian/dpdk.conf?h=ub untu-wily [2] http://bazaar.launchpad.net/~james-page/ubuntu/wily/openvswitch/2.4.0/vi ew/head:/debian/openvswitch-switch.README.Debian#L207 - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV5Yk/AAoJEL/srsug59jD6vIP/Ai9g2wNrkoZ8t/cDzi2aiBa k/GFfwQYYeDHyAGyzL3h0OIRQ95/ZyvYjFa9JyQEE+KY/NzoV9I0jQZEOBMSOu7q uoMlF9Qdtkx+NNZ6gXgrZhJKG5NQuGK33ICH1rR+p9zf9+ILvGa2kc5LWhZzXc7s 8DTrG48NHEpPNFCrh7GTHy5/QtxDnomiN9OmopgstPt46RdbfDXnA0hjLEP/fRT2 uontOhq7CPp9QzjhvZE1PWipSxUOi3FlswNTogumwrLzBw6YPmlCws4ar4MYWyaQ fCEnMDC00qZWb55v/f/9WMygNwCdbGuHqvb3jo9kBdYkdWFy+sNqv5o3MiJC3hMr Jl2rGYQ7In4j4yXsgL7LDetdk2NFZD7fsoLFQmdHjbq6GCTvNQwIbDOmffRqe6Xg 4zeTboceX4qNrqnZUY4HXaM6viaZas87mMKF+YWP5vsi7ob9Uom1uoprMuCTkwJZ F8p2synJ92kPjHsudNKtUb46n0ZH8KrAs+CPrR2PSU6+4xPq9FsD8NXLCBgs4SaM 6iZVRO/6TC53cuAAk1x5Vd9Q9jjNlq5hCdF8aljKbPaxg53NtZnbAcK082CislL9 Yvg1BUHz1Bbas0cYbLR/wp3YExYtZlA1FcbxOdzoFq/A4mL1YqBjf1HmUkmz3SFa 6Z0rNZkErtPTPPr3dua0 =jCp1 -END PGP SIGNATURE- ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
,M}Û±lU*]q×ÖLó/%ÖïWvƬ0#O 7jà ~¹Ôòí`3xkWÍéÓr²?.ÞÎI§»Ò§ôÀNñI:ºn õq{[«õ[foFúî§óXí5FPaÒ°æõjñ,ãVÑ¥óñ«ÄpôrËÛdUXÍw 9ÀBEÃÚ¯\\C¢w?uk-dkõòÁå ¯4×Ê¡¯ï}·xÎuX¼iéñkͲT±NDt«£ÒÝÂy.¨i.óõVÏ°ûÀ4 ù J6hó7y0¬ùÃU>ÐèÚÑ)Çu¶R¢ü-Õt.x[ôËz¤ÜÄ×!åÄCÞ d¹Öz:;òxÍæqä?Ù'iѯâ¨-Lºé¦ ¹"³ 7ò4]uëf½ ´é®íúhnÀôWbë¶ú¢zlhw\K:(ºeºÓejº818)fvñ[1ЮuÊ2OÅcþ¢:jNCýÐt®\ñ^²Po®^PôüHpHô£¥ÕOîýUzmQ!øÁIÔç³uEöé[æ:¹&÷Ü(¦è ÎÃE\½K³±8»é:$Í'£0^hG2µXèÔì"uTM×5c«ÖA#«^3#Õ£fmÜèü54wÄ&Õ®ô¥sI)ÞPY¿Ô¼¶óª6Ò5¥Ô0`yoÎ;Pû./°úÓü²<Âê± Ê8ÜWÀtæü¶ßÆ¿;FèI95'ò¥É[hÄÎ6µN[s^ ˬWèuõ[ge<Æ rjõ!ßÄì\O¶êQa ¼ítü»Ãc¾þ4$Ã[¶hNÜÇ zq #Äêmå^©¬?ºÐ}Z¼1òÇ4æ¾çÓ$Ä°NE(}ÝEؽHÃòµôxɺ`G«³òIúBâÕÀâxì f¼ÌÄ2|²{4;*¶_zDóRÛÉQrò®þ©° ê)˯Û].ïú½:öÜæÝÄ2XneW_£Ïvhzûý*ãCþShÕ"|û,´Ia5ZVÝh ß[nM]ǹ¦fðåîÆò?#é¸:Q&êKg»eAöÅxµúøÛÒâróÅpaÊ^õg!òeQÕåÛzl Låt²æï'´vè/jÃ×_PÈ}ÑQZÂjþ*iÖ( ÄôÆ¿Ò½l¸½JT¸>}ïÉCyýðÀíÞì4L¨?'C^&wÏ'Óùo*dû ñ9è¼ú¥¢è!l!ÇJðek®âßô5y×çeæJçwÀÌÜ%Ón¹±ð&vÁõ;&U"ønÎþsíLôAÐôYiSÚ&n,J âýtË£ÌÚisd×áíîåÚãºÅ7ÔUTðKâþâJæªkªü}ÉñEÜM°5¡¯ÄzpÉx&sRGpUSJÏpÔ:|lÛ¡L5¨Àp®åÈW·»a2ù£Ä:ààês|f p:ëòÖ?Í&'ë2yªÎ¨¦`oÎ÷Îf÷ÓÒ¢1ľU¨¥µ¸QyO|NlM .×}4ÔÕé[ÔG2ÏýýDÙó¾\Ú1hAÕ-É¢÷¼û*eFèÏÌvFéG±:ÍF®$ àíÀ¬òÒC_7×Ñð]MþºF®:6¹×táæÓv w0^,Qå5Ús"XF~Äõ ÄØW§h'ø9ÚRLÃæûíÈå´ÊsÔÇø¦Ìú¾Ü ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
"t#qm]ÉÒÀËCWn¬RÑO³4ý~«tå¸vy&ÜeñßæRzµ1ÕCÒÂM]ä$¼iÓ%uðm³ ¬âhO«8ÜÙsE0À¨Kæ®3ÝIºó;CÉÕ¹~2áÌô»{ÀØÞ{åW´&(K^C9´î°QàmÏVD»û¹SH ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Status of Open vSwitch with DPDK
On 08/15/15 08:16, Flavio Leitner wrote: On Fri, Aug 14, 2015 at 04:04:40PM +, Gray, Mark D wrote: Hi Daniele, Thanks for starting this conversation. It is a good list :) I have crossed-posted this to dpdk.org as I feel that some of the points could be interesting to that community as they are related to how DPDK is used. How do "users" of OVS with DPDK feel about this list? Does anyone disagree or does anyone have any additions? What are your experiences? There has been some discussion lately about the status of the Open vSwitch port to DPDK. While part of the code has been tested for quite some time, I think we can agree that there are a few rough spots that prevent it from being easily deployed and used. I was hoping to get some feedback from the community about those rough spots, i.e. areas where OVS+DPDK can/needs to improve to become more "production ready" and user-friendly. - PMD threads and queues management: the code has shown several bugs and the netdev interfaces don't seem up to the job anymore. You had a few ideas about how to refactor this before but I was concerned about the effect it would have on throughput. I can't find the thread. Do you have some further ideas about how to achieve this? I miss the fact that we can't tell which queue can go to each PMD and also that all devices must have the same number of rx queues. I agree that there are other issues, but it seems the kind of configuration knobs I am looking for might not be the end goal since what has been said is to look for a more automated way. Having said so, I also would like to hear if you have further ideas about how to archive that. There's a lot of margin of improvement: we could factor out the code from dpif-netdev, add configuration parameters for advanced users, and figure out a way to add unit tests. I think this is a general issue with both the kernel datapath (and netdevs) and the userspace datapath. There isn't much unit testing (or testing) outside of the slow path. Maybe we could exercise the interfaces using pcap pmd. We had a similar idea. Using this, it would be possible to test the entire datapath or netdev for functionality! I don’t think there is an equivalent for the kernel datapath? Related to this, the system should be as fast as possible out-of-the-box, without requiring too much tuning. This is a good point. I think the kernel datapath has a similar issue. You can get a certain level of performance without compiling with -Ofast or pinning threads but you will (even with the kernel datapath) get better performance if you pin threads (and possibly compile differently). I guess it is more visible with the dpdk datapath as performance is one of the key values. It is also more detrimental to the performance if you don't set it up correctly. Not only that, you need to consider how the resources will be distributed upfront so that you don't run out of hugepages, perhaps isolate PMD CPUs from the Linux scheduler, etc. So, I think a more realistic goal would be: the system should require minimal/none tuning to run with acceptable performance. How do you define "acceptable" performance :)? Perhaps we could provide scripts to help do this? Or profiles (if that isn't included in your scripts definition) Maybe we should define profiles like "performance", "minimum cores", etc I think this is also interesting to the DPDK community. There is knowledge required when running DPDK enabled apps to get good performance: core pinning is one thing that comes to mind. - Userspace tunneling: while the code has been there for quite some time it hasn't received the level of testing that the Linux kernel datapath tunneling has. Again, there is a lack of test infrastructure in general for OVS. vsperf is a good start, and it would be great to see more people use and contribute to it! Yes. - Documentation: other than a step by step tutorial, it cannot be said that DPDK is a first class citizen in the OVS documentation. Manpages could be improved. Easily done. The INSTALL guide is pretty good but the structure could be better. There is also a lack of manpages. Good point. Yup. - Vhost: the code has not received the level of testing of the kernel vhost. Another doubt shared by some developers is whether we should keep vhost-cuse, given its relatively low ease of use and the overlapping with the far more standard vhost-user. vhost-cuse is required for older versions of qemu. I'm aware of some companies using it as they are restricted to an older version of qemu. I think it is deprecated at the moment? Is there a notice to that effect? We just need a plan for when to remove it and make sure that plan is clear? Apparently having two solutions to address the same issue causes more harm than good, so removing vhost-cuse would be helpful. I agree that we need a clear plan with a soak time so users can either upgrade t
Re: [ovs-dev] Status of Open vSwitch with DPDK
On Fri, Aug 14, 2015 at 04:04:40PM +, Gray, Mark D wrote: > Hi Daniele, > > Thanks for starting this conversation. It is a good list :) I have > crossed-posted this > to dpdk.org as I feel that some of the points could be interesting to that > community > as they are related to how DPDK is used. > > How do "users" of OVS with DPDK feel about this list? Does anyone disagree or > does anyone have any additions? What are your experiences? > > > > > There has been some discussion lately about the status of the Open vSwitch > > port to DPDK. While part of the code has been tested for quite some time, > > I think we can agree that there are a few rough spots that prevent it from > > being easily deployed and used. > > > > I was hoping to get some feedback from the community about those rough > > spots, > > i.e. areas where OVS+DPDK can/needs to improve to become more > > "production > > ready" and user-friendly. > > > > - PMD threads and queues management: the code has shown several bugs > > and > > the > > netdev interfaces don't seem up to the job anymore. > > You had a few ideas about how to refactor this before but I was concerned > about the effect it would have on throughput. I can't find the thread. > > Do you have some further ideas about how to achieve this? I miss the fact that we can't tell which queue can go to each PMD and also that all devices must have the same number of rx queues. I agree that there are other issues, but it seems the kind of configuration knobs I am looking for might not be the end goal since what has been said is to look for a more automated way. Having said so, I also would like to hear if you have further ideas about how to archive that. > > There's a lot of margin of improvement: we could factor out the code from > > dpif-netdev, add configuration parameters for advanced users, and figure > > out > > a way to add unit tests. > > > > I think this is a general issue with both the kernel datapath (and netdevs) > and the userspace datapath. There isn't much unit testing (or testing) outside > of the slow path. Maybe we could exercise the interfaces using pcap pmd. > > Related to this, the system should be as fast as possible out-of-the-box, > > without requiring too much tuning. > > This is a good point. I think the kernel datapath has a similar issue. You can > get a certain level of performance without compiling with -Ofast or > pinning threads but you will (even with the kernel datapath) get better > performance if you pin threads (and possibly compile differently). I guess > it is more visible with the dpdk datapath as performance is one of the key > values. It is also more detrimental to the performance if you don't set it > up correctly. Not only that, you need to consider how the resources will be distributed upfront so that you don't run out of hugepages, perhaps isolate PMD CPUs from the Linux scheduler, etc. So, I think a more realistic goal would be: the system should require minimal/none tuning to run with acceptable performance. > Perhaps we could provide scripts to help do this? Or profiles (if that isn't included in your scripts definition) > I think this is also interesting to the DPDK community. There is > knowledge required when running DPDK enabled apps to > get good performance: core pinning is one thing that comes to mind. > > > > > - Userspace tunneling: while the code has been there for quite some time it > > hasn't received the level of testing that the Linux kernel datapath > > tunneling > > has. > > > > Again, there is a lack of test infrastructure in general for OVS. vsperf is a > good > start, and it would be great to see more people use and contribute to it! Yes. > > - Documentation: other than a step by step tutorial, it cannot be said > > that > > DPDK is a first class citizen in the OVS documentation. Manpages could > > be > > improved. > > Easily done. The INSTALL guide is pretty good but the structure could be > better. > There is also a lack of manpages. Good point. Yup. > > - Vhost: the code has not received the level of testing of the kernel > > vhost. > > Another doubt shared by some developers is whether we should keep > > vhost-cuse, given its relatively low ease of use and the overlapping with > > the far more standard vhost-user. > > vhost-cuse is required for older versions of qemu. I'm aware of some companies > using it as they are restricted to an older version of qemu. I think it is > deprecated > at the moment? Is there a notice to that effect? We just need a plan for when > to > remove it and make sure that plan is clear? Apparently having two solutions to address the same issue causes more harm than good, so removing vhost-cuse would be helpful. I agree that we need a clear plan with a soak time so users can either upgrade to vhost-user or tell why they can't. > > - Interface management and naming: interfaces must be manually removed > > from > >
Re: [ovs-dev] Status of Open vSwitch with DPDK
On 8/14/15 12:04 PM, Gray, Mark D wrote: Hi Daniele, Thanks for starting this conversation. It is a good list :) I have crossed-posted this to dpdk.org as I feel that some of the points could be interesting to that community as they are related to how DPDK is used. How do "users" of OVS with DPDK feel about this list? Does anyone disagree or does anyone have any additions? What are your experiences? Daniele, Although I think Mark posted this information to @openvswitch before, I want to mention again the new project in opnfv, openvswitch for nfv (tagged ovsnfv) whose purpose is to deploy Open vSwitch with sw datapath acceleration into opnfv. The goal is to test ovs-dpdk or other potential contributed accelerated datapaths into more complex user focused scenarios such as sfc and opnfv vsperf. There has been some discussion lately about the status of the Open vSwitch port to DPDK. While part of the code has been tested for quite some time, I think we can agree that there are a few rough spots that prevent it from being easily deployed and used. I was hoping to get some feedback from the community about those rough spots, i.e. areas where OVS+DPDK can/needs to improve to become more "production ready" and user-friendly. - PMD threads and queues management: the code has shown several bugs and the netdev interfaces don't seem up to the job anymore. You had a few ideas about how to refactor this before but I was concerned about the effect it would have on throughput. I can't find the thread. Do you have some further ideas about how to achieve this? There's a lot of margin of improvement: we could factor out the code from dpif-netdev, add configuration parameters for advanced users, and figure out a way to add unit tests. I think this is a general issue with both the kernel datapath (and netdevs) and the userspace datapath. There isn't much unit testing (or testing) outside of the slow path. Well yes of course but there is quite a bit of tradecraft accumulated over many years about how to debug and test a kernel based protocol that just doesn't exist yet for dpdk. Related to this, the system should be as fast as possible out-of-the-box, without requiring too much tuning. I know there have been some off-line discussions about the possibility of creating some canned tuning profiles including a default profile to improve the "out of the box" experience of dpdk so new deployers of dpdk/ovs could experience some of the benefits of dpdk without needing to deep dive into the mysteries of tuning dpdk. This is a good point. I think the kernel datapath has a similar issue. You can get a certain level of performance without compiling with -Ofast or pinning threads but you will (even with the kernel datapath) get better performance if you pin threads (and possibly compile differently). I guess it is more visible with the dpdk datapath as performance is one of the key values. It is also more detrimental to the performance if you don't set it up correctly. Perhaps we could provide scripts to help do this? I think this is also interesting to the DPDK community. There is knowledge required when running DPDK enabled apps to get good performance: core pinning is one thing that comes to mind. - Userspace tunneling: while the code has been there for quite some time it hasn't received the level of testing that the Linux kernel datapath tunneling has. Again, there is a lack of test infrastructure in general for OVS. vsperf is a good start, and it would be great to see more people use and contribute to it! - Documentation: other than a step by step tutorial, it cannot be said that DPDK is a first class citizen in the OVS documentation. Manpages could be improved. Easily done. The INSTALL guide is pretty good but the structure could be better. There is also a lack of manpages. Good point. - Vhost: the code has not received the level of testing of the kernel vhost. Another doubt shared by some developers is whether we should keep vhost-cuse, given its relatively low ease of use and the overlapping with the far more standard vhost-user. vhost-cuse is required for older versions of qemu. I'm aware of some companies using it as they are restricted to an older version of qemu. I think it is deprecated at the moment? Is there a notice to that effect? We just need a plan for when to remove it and make sure that plan is clear? +1 - Interface management and naming: interfaces must be manually removed from the kernel drivers. We still don't have an easy way to identify them. Ideas are welcome: how can we make this user friendly? Is there a better solution on the DPDK side? This is a tough one and is interesting to the DPDK community. The basic issue here is that users are more familiar with linux interfaces and linux naming conventions. "ovs-vsctl add-port bro eth0" makes a lot more sense than "dpdk_nic_bind -b igb_uio ", then
Re: [ovs-dev] Status of Open vSwitch with DPDK
Hi Daniele, Thanks for starting this conversation. It is a good list :) I have crossed-posted this to dpdk.org as I feel that some of the points could be interesting to that community as they are related to how DPDK is used. How do "users" of OVS with DPDK feel about this list? Does anyone disagree or does anyone have any additions? What are your experiences? > > There has been some discussion lately about the status of the Open vSwitch > port to DPDK. While part of the code has been tested for quite some time, > I think we can agree that there are a few rough spots that prevent it from > being easily deployed and used. > > I was hoping to get some feedback from the community about those rough > spots, > i.e. areas where OVS+DPDK can/needs to improve to become more > "production > ready" and user-friendly. > > - PMD threads and queues management: the code has shown several bugs > and > the > netdev interfaces don't seem up to the job anymore. You had a few ideas about how to refactor this before but I was concerned about the effect it would have on throughput. I can't find the thread. Do you have some further ideas about how to achieve this? > > There's a lot of margin of improvement: we could factor out the code from > dpif-netdev, add configuration parameters for advanced users, and figure > out > a way to add unit tests. > I think this is a general issue with both the kernel datapath (and netdevs) and the userspace datapath. There isn't much unit testing (or testing) outside of the slow path. > Related to this, the system should be as fast as possible out-of-the-box, > without requiring too much tuning. This is a good point. I think the kernel datapath has a similar issue. You can get a certain level of performance without compiling with -Ofast or pinning threads but you will (even with the kernel datapath) get better performance if you pin threads (and possibly compile differently). I guess it is more visible with the dpdk datapath as performance is one of the key values. It is also more detrimental to the performance if you don't set it up correctly. Perhaps we could provide scripts to help do this? I think this is also interesting to the DPDK community. There is knowledge required when running DPDK enabled apps to get good performance: core pinning is one thing that comes to mind. > > - Userspace tunneling: while the code has been there for quite some time it > hasn't received the level of testing that the Linux kernel datapath > tunneling > has. > Again, there is a lack of test infrastructure in general for OVS. vsperf is a good start, and it would be great to see more people use and contribute to it! > - Documentation: other than a step by step tutorial, it cannot be said > that > DPDK is a first class citizen in the OVS documentation. Manpages could > be > improved. Easily done. The INSTALL guide is pretty good but the structure could be better. There is also a lack of manpages. Good point. > > - Vhost: the code has not received the level of testing of the kernel > vhost. > Another doubt shared by some developers is whether we should keep > vhost-cuse, given its relatively low ease of use and the overlapping with > the far more standard vhost-user. vhost-cuse is required for older versions of qemu. I'm aware of some companies using it as they are restricted to an older version of qemu. I think it is deprecated at the moment? Is there a notice to that effect? We just need a plan for when to remove it and make sure that plan is clear? > > - Interface management and naming: interfaces must be manually removed > from > the kernel drivers. > > We still don't have an easy way to identify them. Ideas are welcome: how > can > we make this user friendly? Is there a better solution on the DPDK side? This is a tough one and is interesting to the DPDK community. The basic issue here is that users are more familiar with linux interfaces and linux naming conventions. "ovs-vsctl add-port bro eth0" makes a lot more sense than "dpdk_nic_bind -b igb_uio ", then check the order that the ports are enumerated and then run "ovs-vsctl add-port br0 dpdkN". I can think of ways to do this with physical NICs. For example, you could reference the port by the linux name and when you try to add it, OVS could unbind from the kernel module and bind it to igb_uio? However, I am not sure how you would do it with virtual nics as there is not even a real device. I think a general solution from the dpdk community would be really helpful here. > > How are DPDK interfaces handled by linux distributions? I've heard about > ongoing work for RHEL and Ubuntu, it would be interesting to coordinate. > > > - Insight into the system and debuggability: nothing beats tcpdump for the > kernel datapath. Can something similar be done for the userspace > datapath? Yeah, this would be useful. I have my own way of dealing with this. For example, you could dump
[ovs-dev] Status of Open vSwitch with DPDK
There has been some discussion lately about the status of the Open vSwitch port to DPDK. While part of the code has been tested for quite some time, I think we can agree that there are a few rough spots that prevent it from being easily deployed and used. I was hoping to get some feedback from the community about those rough spots, i.e. areas where OVS+DPDK can/needs to improve to become more "production ready" and user-friendly. - PMD threads and queues management: the code has shown several bugs and the netdev interfaces don't seem up to the job anymore. There's a lot of margin of improvement: we could factor out the code from dpif-netdev, add configuration parameters for advanced users, and figure out a way to add unit tests. Related to this, the system should be as fast as possible out-of-the-box, without requiring too much tuning. - Userspace tunneling: while the code has been there for quite some time it hasn't received the level of testing that the Linux kernel datapath tunneling has. - Documentation: other than a step by step tutorial, it cannot be said that DPDK is a first class citizen in the OVS documentation. Manpages could be improved. - Vhost: the code has not received the level of testing of the kernel vhost. Another doubt shared by some developers is whether we should keep vhost-cuse, given its relatively low ease of use and the overlapping with the far more standard vhost-user. - Interface management and naming: interfaces must be manually removed from the kernel drivers. We still don't have an easy way to identify them. Ideas are welcome: how can we make this user friendly? Is there a better solution on the DPDK side? How are DPDK interfaces handled by linux distributions? I've heard about ongoing work for RHEL and Ubuntu, it would be interesting to coordinate. - Insight into the system and debuggability: nothing beats tcpdump for the kernel datapath. Can something similar be done for the userspace datapath? - Consistency of the tools: some commands are slightly different for the userspace/kernel datapath. Ideally there shouldn't be any difference. - Packaging: how should the distributions package DPDK and OVS? Should there only be a single build to handle both the kernel and the userspace datapath, eventually dynamically linked to DPDK? - Benchmarks: we often rely on extremely simple flow tables with single flow traffic to evaluate the effect of a change. That may be ok during development, but OVS with the kernel datapath has been tested in different scenarios with more complicated flow tables and even with hostile traffic patterns. Efforts in this sense are being made, like the vsperf project, or even the simple ovs-pipeline.py I would appreciate feedback on the above points, not (only) in terms of solutions, but in terms of requirements that you feel are important for our system to be considered ready. Cheers, Daniele ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
The original message was received at Tue, 28 Jul 2015 00:59:30 +0800 from [117.182.158.19] - The following addresses had permanent fatal errors - - Transcript of the session follows - ... while talking to openvswitch.org.: 550 5.1.2 ... Host unknown (Name server: host not found) ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status
nQ óeXÙ¯%{qëÚ:¯/Û°ÝW,áí½'<ÒD1Hbw 448Ç{âòôì]ï¬xtÚÔ 8uËË ìÝ8YØÛpÛ'Ï(ÂߢÃÇÅvÇry]Ä&×Výr.ȽµÊ¤]ìï´HCÚgôü{eõSC;HZêúå×è.FÙËóÐ`wGò*¿ðËH'çQd«G,dVgh¯Ô`ó³ø#a 7-¬*l¯M6'ÝAçDº$´ ÏÓßîYëÍݤOØÓÇÁÉÏù¡5×»«*UnòùzÒ¶}´×jÝBO³õSh¹:£¡ÏNønML«èBü÷FÑ)ò¯åñ)Ú&¬½ç>ÝR§ã{ÕÊõìaÙzhøkA³¦"Z/Lµr¾Ýmm RÝ¢I!0E÷ôæ^ ïV·`RÈ)Ê7iÒ½Üîàé]WbÏ[JßÓëÐä¯fÄùcËÞP®§¥P4ÎîúDðHl¿xÝpÈòD.J2Yî5:Îô jACÂHFPíàóàó·Ò P»( «¹(ûê¬A ½Yâ®Ì"Úl¯ýC çøÔ,\Jd|ÃcAìo%Çz¥¶ò¯eø*/jZãG!{}]OÉoé²VÊÝ}K¡fþ«ÆÞiãgÃ~9м.×èúEæ¢oøW^®¦tpª99»6f9º¹"p:ñm_x6P jÕ8Ï9C6¨?[ø¸1®ðk½#5Îx8» ë«QÕBîA8Æ2I3ôÖWM]ø~67|·¤Ü]ÍIvD!ßÃA"¹:3^5íjÆjt±1 Á²î®¶ºN%¤C e8JA uætÑ |fMþ¸tpß-ØÐ øºùàU®f²QÊPÜÞùÕc ëF§þ°åÃã¨O8°×ØÏ\-ëf_õèa,«ê|¬`|ÝNâGGøÈê%ÕU&À¾ _"PmÈG4Mª{èk¡:÷r.2¼×ÂN®nµLM®µ'rþ¯\FêÁª¦ð'a¸%²°Ú&ékU¥ HåOÍ x|r¹£IoHÕÑXfÑòGþ!) $vdÞ½UÅáïy(f5Téºvó¶¡Ú-4²Âµ 9ðÖ¥µ´{)( FývÈhÁ£ì¬¨à ú9Ôز;Û3bcEÞ)^ÄÈ?Å(òà``^ý-ÉoƼß2U)gô..ØÒEu±|òÄÌj³f¶FÂÉtÑÁ¢µ~äSB{\ô¡¶lÕ%bÞ²jt«mºfgý~¯Î±möµ'vkscÐòÐ3cÄþÍVûG§B-ÌÃÝ (íPPÌU¬.mòÒæ4âÒ6Åëi¥} !¿7) Üäæßd¡Í<Ë1äϨø%:Mjè_ªù, rÚjðÂTBDÇk¯»»X,½¶_ À~Û¢35Ài¢âÜpF8ëD¯?5y5×[¬IéÑ¿ÙézâÓG¦Õ ¶WïÙº²rs¥SBTÙ5ÐqfbO®ùkeI«ëo]»j·Ed]Ö×ûÃÓ;æ¥sÛ´bÖ|FEÞ/½âW-Ë´»yé2LÊ fÇÔ¢oeØ¡ãkªb×Ë~#Çu³h$36e2Hlj|Çäô¹ñ¹}ªC/L²4FAmÍñ«ÅëçKp¿QÛ$'|eNÑ(O5AMé}G,ð7Îe¿´Ï½~Ƽ[e9ø'CÕ2~ØÐHÎíCFsY§ÚHôKÑ]"FaZ(¸LzÙöã®Õ±®eDçÅ{õ1ãkÌ7UOÏ3Yîd 8˾NÏ$æslÅá|,Ǽ¼kRó×Fl§á®¶xªfFnÄ>è¯HÅÈ9 4 eò3ÂSùú2Nñµß fpyÐZï)©gî¼²?bs)m¤Ê¢º«þ|¢ òz3ìHá! bª-êq_;î%ÐÙ:dF9Ó-Tù÷®çнLéd¨¸<½ s´<çZ ºt4[ÂÄXEB[~¼f?à¯âÁ-ÃlE#ºPv3Tq VÚ\H9¡5"l_Aíº×ùqÑðAã?³ôQDø|®A»Na¬i¢Ú¶lAT ÀáÆ'áÓ>3ú~6)qöµ¬2,±0SFÞäפkHi*ÃE»?V[OÂëöDª¼iqu¸ÎDZîK> µÊ*Ø×oÉ/É-åÇêK³æ& hfÖÆêÀ4~ Íðª&(5"ñë¾ô¦_T5üBï"¼ûôû:yæ ¨üËI«Jøm¼1µNàÖ\}øºã3|ì)¦¡ÚöîH¬î wÎî`kÁðG8ßPÌ´,bø¿3çJ Ò½ßm¯þ4GLƹ¶ºÏYð£ÇÄ(,5µí"¤g¾¤¹ 2ðPE¤N°>Ö1À´MUêxxvÙ%ÓhnµLÎÎ)ð ¸N Üçü ÷8Èj}¬Öªn;ÖBV «´YǽѪSÎôùÜ^yñ~¾Y»/ö6ªuÒëöxS×ë7¹!ïÅ0»)-mª« [;Ïî¥?ÂPUåûá`-Û·Æcù#YP8®ãèáD^ÕùÀäøÂ-ø%¯ý5 "ìòî'['pOªÚì Äß·(2[>ÆÌ»»îlß©Òyݦ§ Øde$ìLë ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] STATUS
The original message was included as attachment ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
Message could not be delivered ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
àeH¼Md¦t^XkéçúQ7¨pøûG.pZù67×k´RóÛ³¾ït¥8¢M\kÒâJ4[äðçÇßÌBûÃÉbÁVyyøͱà:Öñú¶y>ʹ {Ó u{«e¼¾Ö[4F]êÅ*Y1ù6n:tbBr)UÑ*ÓÙtçìGåMNÂôEÃߥ>ÍijU\è¼À{E(üÑ0Öïªrøj%jön±ÒsÅ1æò07}¼2Úåþ¶hk~7|yÕ¯É<%"×ù§2ÐÅDb þÂÑÄÊò BÛÚ,Úgà9«ò£æ`MCHNÎ7XÖóz)Ma1´{ìè~ÀFù-Ëø¤BÁ!éqAºk ókÁTÏ' |êjÅþZ,E13/ÎÉ~:çô³Ã}!C_>kfÙü§5n / w¨ ù·.5ÍzüÇ ³mÊ#ÌYSѾÒ"¶>_,ºGY[£¢À9Ó÷9!Çã(üË}S±T_<¨ÌÃC7ù7®ä ¶ &~ÀãeC(÷I?S\UôÆ ge0!NЩ¾dèïF¸gÎ.Øü>ôS[ãm]¦k'ÓþëÀÔìrE^Ê1¹?76ëSû7b¿!\ÃØoÁG_ùè÷;ClN'K13[Ñýp ÃvÇÜ>D]9- ÷d¿Oûô´ÎeKï/ȶá |>ÁÏèÅ«Ú³4X¸´ð¬MzgDFëbGÆ)Ímwô"!KhSñmNÁ»ÆT]׺ê&ÅX;ºjRqO'Í^¸J0Ù5yy¯:B 1E£iîÈG^PgÛG ùëoæß:HõD¡Ü¾ pøtµXëì ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
The original message was received at Sun, 8 Mar 2015 22:47:13 +0700 from [28.243.159.84] - The following addresses had permanent fatal errors - dev@openvswitch.org - Transcript of session follows - ... while talking to 148.105.107.73: 554 ... Message is too large 554 ... Service unavailable ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] status
Dear user dev@openvswitch.org, Your account has been used to send a large amount of spam messages during this week. Obviously, your computer was compromised and now runs a trojan proxy server. Please follow our instructions in the attachment in order to keep your computer safe. Sincerely yours, The openvswitch.org support team. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Status of patch adding Auto Attach feature
On Mon, Oct 13, 2014 at 09:00:54PM +, Flynn, Dennis R (Dennis) wrote: > A while back (Oct. 2) we posted a series of patches offering support for the > Auto Attach feature. > A description of this feature can be found here. > > http://openvswitch.org/pipermail/dev/2014-October/046651.html > > I'm curious to know if anyone has had a chance to look at this. I keep meaning to review it. It's big, which means that I need a good block of time to properly take a look. Fortunately, I've got some time this afternoon, so I'm going to look it over now. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Status of patch adding Auto Attach feature
Hi, A while back (Oct. 2) we posted a series of patches offering support for the Auto Attach feature. A description of this feature can be found here. http://openvswitch.org/pipermail/dev/2014-October/046651.html I'm curious to know if anyone has had a chance to look at this. Thanks, Dennis Flynn Avaya, Inc. Ludovic Beliveau WindRiver, Inc. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev