<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel">
    <title>gmane.network.openvswitch.devel</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10817"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10816"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10815"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10814"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10813"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10812"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10811"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10810"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10809"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10808"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10807"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10806"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10805"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10804"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10803"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10802"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10801"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10800"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10799"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openvswitch.devel/10798"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10817">
    <title>You have been awarded</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10817</link>
    <description>&lt;pre&gt;&lt;/pre&gt;</description>
    <dc:creator>Good News</dc:creator>
    <dc:date>2012-05-26T08:52:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10816">
    <title>Participa en el sorteo de un iPad3</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10816</link>
    <description>&lt;pre&gt;Si no visualiza correctamente la newsletter pinche aquí
&amp;lt;http://www.integralecommerce.com/news/newsletter1205php.html&amp;gt;
.
&amp;lt;http://www.integralecommerce.com&amp;gt;

Suscríbete antes del 31 de mayo 

y participarás en el sorteo de 

un Resolucionario Nuevo iPad 3 de apple.
&amp;lt;http://mailing.integralecommerce.com/newsintegral/lists/?p=subscribe&amp;gt;


&amp;lt;http://mailing.integralecommerce.com/newsintegral/lists/?p=subscribe&amp;gt;

Bases del concurso:

 Todos los usuarios que acepten recibir información de
IntegralEcommerce.com o de cualquiera de las tiendas gestionadas por
Transimgrup Serveis SL
&amp;lt;http://mailing.integralecommerce.com/newsintegral/lists/?p=subscribe&amp;gt;

 Recibirá un correo entre el 1 y el 5 de junio con el número para
participar en el sorteo.
 El número ganador deberá coincidir con las 5 cifras del número
premiado en el sorteo de la ONCE del día 08/06/2012.

NUESTRAS TIENDAS GESTIONADAS
http://www.asofert.com

http://www.baro-online.com

http://www.loslicores.com

http://www.hoko-esport.com

http://www.virgini&lt;/pre&gt;</description>
    <dc:creator>news-Ju2OFlXtBjL2CRcdCeAgGQ&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-05-25T13:36:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10815">
    <title>[PATCH] ofp-util: Clean up cookie handling.</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10815</link>
    <description>&lt;pre&gt;Commit e72e793 (Add ability to restrict flow mods and flow stats
requests to cookies.) modified cookie handling.  Some of its behavior
was unintuitive and there was at least one bug (described below).
Commit f66b87d (DESIGN: Document uses for flow cookies.) attempted to
document a clean design for cookie handling.  This commit updates the
DESIGN document and brings the implementation in line with it.

In commit e72e793, the code that handled processing OpenFlow flow
modification requests set the cookie mask to exact-match.  This seems
reasonable for adding flows, but is not correct for matching, since
OpenFlow 1.0 doesn't support matching based on the cookie.  This commit
changes to cookie mask to fully wildcarded, which is the correct
behavior for modifications and deletions.  It doesn't cause any problems
for flow additions, since the mask is ignored for that operation.

Bug #9742

Reported-by: Luca Giraudo &amp;lt;lgiraudo-l0M0P4e3n4LQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Reported-by: Paul Ingram &amp;lt;paul-l0M0P4e3n4LQT0dZR+&lt;/pre&gt;</description>
    <dc:creator>Justin Pettit</dc:creator>
    <dc:date>2012-05-26T01:48:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10814">
    <title>Re: [PATCH] ofp-util: Clean up cookie handling.</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10814</link>
    <description>&lt;pre&gt;

Fixed.


After many off-line discussions, I think we came up with a solution we both found satisfactory.  I'll send an updated version of this patch soon, which contains lots of details on the design.


Agreed.  I tried a few different ones and settled on one that was not fantastic.  I've changed it to "&amp;lt;used&amp;gt;" and "-" for used and invalid, respectively.


Thanks for catching that.


Updated.


Done.


Fixed.


I changed the logic around so that only adds and modifies are allowed to update the cookie without a fatal error.



The protocol version wasn't available, and I was planning to disambiguate modifications later based on the version.  Regardless, the new version changes all of that, and this comment was dropped.

Thanks for the review.  I'll send out v2 shortly.

--Justin


&lt;/pre&gt;</description>
    <dc:creator>Justin Pettit</dc:creator>
    <dc:date>2012-05-26T01:48:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10813">
    <title>[loss-report 3/4] dpif-linux: Slightly refactor internaldata structures.</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10813</link>
    <description>&lt;pre&gt;An initial attempt also replaced the 'uint32_t ready_mask' in struct
dpif_linux by a 'bool ready' in each struct dpif_channel, but I wasn't
happy with the result (the ready_mask bitmap works out really well) and so
I dropped that part.

Signed-off-by: Ben Pfaff &amp;lt;blp-l0M0P4e3n4LQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
---
 lib/dpif-linux.c |   67 +++++++++++++++++++++++++++++-------------------------
 1 files changed, 36 insertions(+), 31 deletions(-)

diff --git a/lib/dpif-linux.c b/lib/dpif-linux.c
index 9d84edd..4de44a8 100644
--- a/lib/dpif-linux.c
+++ b/lib/dpif-linux.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -61,10 +61,10 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 VLOG_DEFINE_THIS_MODULE(dpif_linux);
 enum { MAX_PORTS = USHRT_MAX };
 
-enum { N_UPCALL_SOCKS = 17 };
-BUILD_ASSERT_DECL(IS_POW2(N_UPCALL_SOCKS - 1));
-BUILD_ASSERT_DECL(N_UPCALL_SOCKS &amp;gt; 1);
-BUILD_ASSERT_DECL(N_UPCALL_SOCKS &amp;lt;= 32); /* We use a 32-bit word as a mask. */
+enum { N_CHANNELS = 17 };
+BUILD_ASSERT_DECL(IS_POW2(N_CHANNELS - 1));
+BUILD_ASSERT_DECL(N_CHANNELS &amp;gt; 1);
+BUILD_ASSERT_DECL(N_CHANNELS &amp;lt;= 32); /* We use a 32&lt;/pre&gt;</description>
    <dc:creator>Ben Pfaff</dc:creator>
    <dc:date>2012-05-25T21:36:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10812">
    <title>[loss-report 4/4] dpif-linux: Log details when a packetis lost.</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10812</link>
    <description>&lt;pre&gt;Until now, when a packet was dropped in the kernel-to-user buffers, we
logged the occurrence but nothing that would allow a person reading the
log after the fact to learn why it was dropped.  This commit adds details
that identify the major sources of packets in the buffer, which should
help.

Signed-off-by: Ben Pfaff &amp;lt;blp-l0M0P4e3n4LQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
---
 lib/dpif-linux.c |  189 ++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 files changed, 177 insertions(+), 12 deletions(-)

diff --git a/lib/dpif-linux.c b/lib/dpif-linux.c
index 4de44a8..ada23ef 100644
--- a/lib/dpif-linux.c
+++ b/lib/dpif-linux.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -54,6 +54,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 #include "random.h"
 #include "shash.h"
 #include "sset.h"
+#include "timeval.h"
 #include "unaligned.h"
 #include "util.h"
 #include "vlog.h"
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -130,10 +131,58 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int dpif_linux_flow_transact(struct dpif_linux_flow *request,
 static void dpif_linux_flow_get_stats(const struct dpif_linux_flow *,
                                       struct dpif_flow_stats *);
 
+/&lt;/pre&gt;</description>
    <dc:creator>Ben Pfaff</dc:creator>
    <dc:date>2012-05-25T21:36:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10811">
    <title>[loss-report 2/4] dpif-linux: Avoid pessimal behaviorwhen kernel-to-user buffers overflow.</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10811</link>
    <description>&lt;pre&gt;When a kernel-to-user Netlink buffer overflows, the kernel reports
ENOBUFS without passing along an actual message.  When it does this,
we should immediately try again, because we know that there is a
message waiting, instead of reporting the error to the caller.

This improves the OVS response rate to "hping3 --flood" traffic by
a few percentage points in my testing.

Signed-off-by: Ben Pfaff &amp;lt;blp-l0M0P4e3n4LQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
---
 lib/dpif-linux.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/lib/dpif-linux.c b/lib/dpif-linux.c
index 256c9d6..9d84edd 100644
--- a/lib/dpif-linux.c
+++ b/lib/dpif-linux.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -150,6 +150,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct dpif_linux {
 };
 
 static struct vlog_rate_limit error_rl = VLOG_RATE_LIMIT_INIT(9999, 5);
+static struct vlog_rate_limit enobufs_rl = VLOG_RATE_LIMIT_INIT(60, 5);
 
 /* Generic Netlink family numbers for OVS. */
 static int ovs_datapath_family;
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1138,6 +1139,15 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; dpif_linux_recv(struct dpif *dpif_, struct dpif_upcall *upcall,
 
&lt;/pre&gt;</description>
    <dc:creator>Ben Pfaff</dc:creator>
    <dc:date>2012-05-25T21:36:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10810">
    <title>[loss-report 1/4] poll-loop: More strictly rate-limithigh CPU use.</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10810</link>
    <description>&lt;pre&gt;120 messages per minute just isn't helpful.

Signed-off-by: Ben Pfaff &amp;lt;blp-l0M0P4e3n4LQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
---
 lib/poll-loop.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/poll-loop.c b/lib/poll-loop.c
index ba6c3a1..516cf13 100644
--- a/lib/poll-loop.c
+++ b/lib/poll-loop.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1,5 +1,5 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 /*
- * Copyright (c) 2008, 2009, 2010, 2011 Nicira, Inc.
+ * Copyright (c) 2008, 2009, 2010, 2011, 2012 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -157,7 +157,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; poll_immediate_wake(const char *where)
 static void
 log_wakeup(const char *where, const struct pollfd *pollfd, int timeout)
 {
-    static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(120, 120);
+    static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(10, 10);
     enum vlog_level level;
     int cpu_usage;
     struct ds s;
&lt;/pre&gt;</description>
    <dc:creator>Ben Pfaff</dc:creator>
    <dc:date>2012-05-25T21:36:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10809">
    <title>Re: [ovs-discuss] kernel crash - openvswitch_mod</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10809</link>
    <description>&lt;pre&gt;
I don't think that looking at assembler dumps is the best way to go
about this.  The original poster also mentioned that he saw this with
the Linux bridge so if you're looking at the same thing then OVS code
is probably not the issue.
&lt;/pre&gt;</description>
    <dc:creator>Jesse Gross</dc:creator>
    <dc:date>2012-05-25T20:31:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10808">
    <title>Re: [ovs-discuss] kernel crash - openvswitch_mod</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10808</link>
    <description>&lt;pre&gt;
Hmmm... Yea, Im trying to do some debug on this.

I did the objdump, I think I found the line but I got stuck.

&amp;lt;0&amp;gt;EIP: [&amp;lt;f1f0cd29&amp;gt;] queue_userspace_packet+0x19/0x310 [openvswitch_mod] 
SS:ESP 0069:ef935af4

00001d10 &amp;lt;queue_userspace_packet&amp;gt;:
     1d10:   55                      push   %ebp
     1d11:   89 e5                   mov    %esp,%ebp
     1d13:   57                      push   %edi
     1d14:   56                      push   %esi
     1d15:   53                      push   %ebx
     1d16:   83 ec 30                sub    $0x30,%esp
     1d19:   89 45 d4                mov    %eax,0xffffffd4(%ebp)
     1d1c:   89 55 d0                mov    %edx,0xffffffd0(%ebp)
     1d1f:   89 4d cc                mov    %ecx,0xffffffcc(%ebp)
     1d22:   c7 45 d8 00 00 00 00    movl   $0x0,0xffffffd8(%ebp)
     1d29:   66 83 ba 8c 00 00 00    cmpw   $0x0,0x8c(%edx) &amp;lt;========= 
This line
     1d30:   00
     1d31:   0f 85 e7 01 00 00       jne    1f1e 
&amp;lt;queue_userspace_packet+0x20e&amp;gt;
     1d37:   8b 75 d0          &lt;/pre&gt;</description>
    <dc:creator>Luiz Ozaki</dc:creator>
    <dc:date>2012-05-25T18:59:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10807">
    <title>Re: [PATCH 05/21] vswitchd: Add add_tunnel_ports()</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10807</link>
    <description>&lt;pre&gt;
This seems reasonable at a glance.  There are bits I might quibble
with as this gets closer, but the structure seems reasonable.
&lt;/pre&gt;</description>
    <dc:creator>Ben Pfaff</dc:creator>
    <dc:date>2012-05-25T17:18:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10806">
    <title>Re: MPLS and VLAN QinQ patch</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10806</link>
    <description>&lt;pre&gt;
-----Original Message-----
From: Ben Pfaff [mailto:blp-l0M0P4e3n4LQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org] 
Sent: Friday, May 25, 2012 9:32 AM
To: Kerur, Ravi
Cc: dev-yBygre7rU0TnMu66kgdUjQ&amp;lt; at &amp;gt;public.gmane.org
Subject: Re: [ovs-dev] MPLS and VLAN QinQ patch

On Fri, May 25, 2012 at 01:24:00AM +0200, Ravi.Kerur-+tb+GG71Y8BBDgjK7y7TUQ&amp;lt; at &amp;gt;public.gmane.org wrote:

Yes, that's what I had in mind.

&amp;lt;rk&amp;gt; That's the approach I have taken for kernel code. For userspace, I just thought of using packet-&amp;gt;l3 which is readily available(one can argue the same for kernel as well with skb's). Anyways I will modify the code.

Thanks,
Ravi

Thanks,

Ben.
&lt;/pre&gt;</description>
    <dc:creator>Ravi.Kerur-+tb+GG71Y8BBDgjK7y7TUQ&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-05-25T16:42:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10805">
    <title>Re: MPLS and VLAN QinQ patch</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10805</link>
    <description>&lt;pre&gt;
Yes, that's what I had in mind.

Thanks,

Ben.
&lt;/pre&gt;</description>
    <dc:creator>Ben Pfaff</dc:creator>
    <dc:date>2012-05-25T16:31:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10804">
    <title>Re: MPLS and VLAN QinQ patch</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10804</link>
    <description>&lt;pre&gt;
OK, thanks.

It's entirely possible that we should fine-tune how rate-limiting
works for invalid_ttl (both IP and MPLS).
&lt;/pre&gt;</description>
    <dc:creator>Ben Pfaff</dc:creator>
    <dc:date>2012-05-25T16:30:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10803">
    <title>Re: MPLS and VLAN QinQ patch</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10803</link>
    <description>&lt;pre&gt;Sorry for the confusion, I was not questioning your comments they are valid and I have addressed them. While making changes it occurred to me how invalid_ttl is handled in the controller, will it suffer from similar ttl expiry attack and should rate-limit sending invalid_ttl to controller? Since OVS can rate-limit and invalid_ttl for ip doesn't rate-limit, will leave the code for mpls as it is.


-----Original Message-----
From: Ben Pfaff [mailto:blp-l0M0P4e3n4LQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org] 
Sent: Friday, May 25, 2012 9:14 AM
To: Kerur, Ravi
Cc: dev-yBygre7rU0TnMu66kgdUjQ&amp;lt; at &amp;gt;public.gmane.org
Subject: Re: [ovs-dev] MPLS and VLAN QinQ patch

On Fri, May 25, 2012 at 05:49:30PM +0200, Ravi.Kerur-+tb+GG71Y8BBDgjK7y7TUQ&amp;lt; at &amp;gt;public.gmane.org wrote:

I don't see how your comment is related to mine.  Mine is about properly handling double-decrement to zero.  Yours is about handling decrement to zero in general.

The main rationale is that OpenFlow says to do that.  I wasn't behind that decision.  You could ask the people wh&lt;/pre&gt;</description>
    <dc:creator>Ravi.Kerur-+tb+GG71Y8BBDgjK7y7TUQ&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-05-25T16:27:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10802">
    <title>Re: MPLS and VLAN QinQ patch</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10802</link>
    <description>&lt;pre&gt;
I don't see how your comment is related to mine.  Mine is about
properly handling double-decrement to zero.  Yours is about handling
decrement to zero in general.

The main rationale is that OpenFlow says to do that.  I wasn't behind
that decision.  You could ask the people who were, if you join the
Open Network Foundation "extensibility" mailing list.

There are other dubious OpenFlow choices regarding MPLS, also.

Open vSwitch can limit the rate at which "packet-in"s are sent to the
controller.  This can mitigate the amount of work the controller has
to do.
&lt;/pre&gt;</description>
    <dc:creator>Ben Pfaff</dc:creator>
    <dc:date>2012-05-25T16:13:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10801">
    <title>Re: MPLS and VLAN QinQ patch</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10801</link>
    <description>&lt;pre&gt;I would like to revisit this topic...

ofproto-dpif.c
--------------

I think that say, two, dec_mpls_ttl actions in a single flow, starting from a TTL of, say, 2, will fail to detect reaching TTL 0.  Also, the existing implementation of dec ttl for IP stop translating actions after reaching TTL 0.  Presumably the MPLS implementation should do the same.

&amp;lt;rk&amp;gt; In traditional  network for invalid TTLs(0 and 1) ICMP error msg has to be sent and a TTL expiry handling attack can be easily envisioned with this. Routers usually mitigate this attack via access-list to drop packets with TTL 0/1 (assumption is that network applications usually send with larger TTL value and it's highly unlikely that a packet will ever arrive with TTL 0/1) or rate-limit sending ICMP error message and can be evidenced via traceroute. In OVS, I see every invalid TTL(both IP and MPLS) packet is sent to the controller and I assume controller does rate control on sending ICMP error message  or drop the packet  or do additional processing?  &lt;/pre&gt;</description>
    <dc:creator>Ravi.Kerur-+tb+GG71Y8BBDgjK7y7TUQ&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-05-25T15:49:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10800">
    <title>Re: [ovs-discuss] kernel crash - openvswitch_mod</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10800</link>
    <description>&lt;pre&gt;
No, the caller will perform that check.  rpl_skb_gso_segment() is a
compatibility replacement for skb_gso_segment() on older kernels.  It
needs to return a pointer, not an error code.
_______________________________________________
dev mailing list
dev&amp;lt; at &amp;gt;openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
&lt;/pre&gt;</description>
    <dc:creator>Jesse Gross</dc:creator>
    <dc:date>2012-05-25T14:05:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10799">
    <title>Re: [ovs-discuss] kernel crash - openvswitch_mod</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10799</link>
    <description>&lt;pre&gt;Changed to Dev Mailing...

We might have found the problem in the kernel function 
"skb_gso_segment"... Doing some test to check.

Anyways, looking at the OVS code I see this skb_gso_segment called in 
other places and handled in different ways:
./datapath/vport-netdev.c
./datapath/tunnel.c
./datapath/datapath.c

./datapath/linux/compat/netdevice.c

Doesn't rpl_skb_gso_segment need to check IS_ERR and return the PTR_ERR 
if it's true ?

Does it make sense ?

Something like this:

diff --git a/datapath/linux/compat/netdevice.c 
b/datapath/linux/compat/netdevice.c
index 9e92eeb..7974e8c 100644
--- a/datapath/linux/compat/netdevice.c
+++ b/datapath/linux/compat/netdevice.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -95,6 +95,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct sk_buff *rpl_skb_gso_segment(struct sk_buff 
*skb, u32 features)

         skb_gso = skb_gso_segment(skb, features);
         skb-&amp;gt;protocol = skb_proto;
+       if (IS_ERR(skb))
+               return PTR_ERR(skb);
+
         return skb_gso;
  }
  #endif /* kernel version &amp;lt; 2.6.38 */

&lt;/pre&gt;</description>
    <dc:creator>Luiz Ozaki</dc:creator>
    <dc:date>2012-05-25T10:58:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10798">
    <title>87% Off TESOL Teaching Certification Course</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10798</link>
    <description>&lt;pre&gt;$79 for a 150-Hour Specialist TESOL/TEFL Course from Global Leadership  
College ($599 Value)
Please go to http://www.teacherbuys.com/nationwide/ 
for more details.

Certificate awarded upon completion of course

-150 hours of training from the comfort of your own home or office
-Information including TESOL/TEFL theory and practice
-100% comprehensive
-Easy to follow classes
-Get your certificate in as little as 8 weeks
-Learn and study at your own pace
-A solid base for a career
-Makes a great gift!

Expand your mind, and your future, with today's TeacherBuy!
If you prefer not to receive future Daily Deal emails, you can always  
send email to unsubscribe-7fvPQkbVUmAOZTnbMYOWKg&amp;lt; at &amp;gt;public.gmane.org to unsubscribe.




&lt;/pre&gt;</description>
    <dc:creator>TeacherBuys</dc:creator>
    <dc:date>2012-05-25T10:56:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openvswitch.devel/10797">
    <title>Hello my dear,</title>
    <link>http://permalink.gmane.org/gmane.network.openvswitch.devel/10797</link>
    <description>&lt;pre&gt;

Hello my dear,

With great respect and honour i am writing to you this mail.Please pardon me if i interfere into your privacy,My name is Miss Mercy Joseph Young, 23 years of age, i am the only daughter of Late Dr Joseph Young from Ivory Coast, my father was the owner of Joseph Cocoa Industries Limited and he was a personal adviser to our former Head of State (late General Robert Guei). My purpose of contacting you is first, i want to know more about you so that i will know the areas you will be of assistance to my needs. I have some reasonable amount of moneys which my parents left for me before their untimely death, i want to plan for my future by investing this money in a good and profitable business but I don’t know where to start and that is why I got interested in contacting you hoping that you will be kind a sincere to me by leading me through the right process to see that this money is not wasted because it is my only hope of planning for my future .Please,
 don’t be surprise or scared because a&lt;/pre&gt;</description>
    <dc:creator>Mercy Joseph</dc:creator>
    <dc:date>2012-05-25T09:54:39</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.network.openvswitch.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.network.openvswitch.devel</link>
  </textinput>
</rdf:RDF>

