OVS needs to segments large skb before sending it for miss
packet handling to userspace. but skb_gso_segment uses
skb->cb. This corrupted OVS_CB which result in following panic.
[ 735.419921] BUG: unable to handle kernel paging request at 001401b2
[ 735.423168] Oops: [#1] SMP DEBUG_
On Thu, Sep 18, 2014 at 5:48 AM, Thomas Graf wrote:
> Port datapath to work with kernrels up to 3.17 and use 3.16.2 as
> the new kernel for CI testing.
>
> Tested with 3.14, 3.16.2, and net-next (3.17).
>
> Signed-off-by: Thomas Graf
> Co-authored-by: Madhu Challa
> ---
> v2:
> - Swapped ignore
On Fri, Sep 19, 2014 at 2:13 PM, Andy Zhou wrote:
> Looks good. A few minor comments in line.
> Acked-by: Andy Zhou
>
I fixed according to comments and pushed to master.
> It would be good to add some more back ground information in the commit
> message.
>
> On Wed, Sep 17, 2014 at 4:08 PM, P
On Thu, Sep 18, 2014 at 11:31 PM, Andy Zhou wrote:
> look good in general. a few small comments in line.
>
> Acked-by: Andy Zhou
>
> On Wed, Sep 17, 2014 at 6:58 PM, Pravin B Shelar wrote:
>> OVS keeps pointer to packet key in skb->cb, but the packet key is
>> store on stack. This could make cod
On 9/20/14, 10:38 AM, Jiri Pirko wrote:
Sat, Sep 20, 2014 at 07:21:10PM CEST, sfel...@cumulusnetworks.com wrote:
On Sep 20, 2014, at 5:51 AM, Roopa Prabhu wrote:
On 9/20/14, 1:10 AM, Scott Feldman wrote:
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu
wrote:
On 9/19/14, 8:49 AM, Jiri Pirko w
On 9/20/14, 12:31 PM, "Ben Pfaff" wrote:
>On Sat, Sep 20, 2014 at 07:23:30PM +, Daniele Di Proietto wrote:
>> * Most importantly, many implementation of thread local storage (e.g.
>> C11) do not allow cross-thread access (there?s a big comment in
>> lib/ovs-thread.h).
>
>That's what the s
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 the
On Sat, Sep 20, 2014 at 3:53 AM, Thomas Graf wrote:
> On 09/20/14 at 10:14am, Jiri Pirko wrote:
>> Sat, Sep 20, 2014 at 12:12:12AM CEST, john.r.fastab...@intel.com wrote:
>> >I was considering a slightly different approach where the
>> >device would report via netlink the fields/actions it
>> >sup
On Sep 20, 2014, at 12:12 PM, Daniele Di Proietto
wrote:
> Sometimes we need to read and write 64-bit values (statistics) from multiple
> threads. On 64-bit architectures it si possible to read 64-bit data while it
> is
> being written without worrying about consistency.
> On 32-bit architectu
On Sat, Sep 20, 2014 at 07:23:30PM +, Daniele Di Proietto wrote:
> * Most importantly, many implementation of thread local storage (e.g.
> C11) do not allow cross-thread access (there?s a big comment in
> lib/ovs-thread.h).
That's what the standard says but I think that it is basically nonse
Signed-off-by: Daniele Di Proietto
---
lib/dpif-netdev.c | 70 ++-
1 file changed, 23 insertions(+), 47 deletions(-)
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 90fe01c..e5f2aa0 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.
Hi Ethan,
As you know I¹ve been working on similar problems for the userspace
datapath. Also, I¹m about to post a patch series to reduce the overhead of
counting (global, not per-flow) stats in dpif-netdev.c.
Here are some thoughts :
* I definitely think it¹s a good idea to use ovsthread_stats fo
Sometimes we need to read and write 64-bit values (statistics) from multiple
threads. On 64-bit architectures it si possible to read 64-bit data while it is
being written without worrying about consistency.
On 32-bit architectures have to use some form of synchronization to make sure
that we are re
I'm doing some performance testing which heavily stresses the OVS DPDK slow
path, and notice we spend a ridiculous amount of CPU time on the rule_dpif stats
mutex. For my test case, by commenting out the mutex I literally doubled the
performance. I'm in a bit of a rush, so as a short term hack, I
Sat, Sep 20, 2014 at 07:21:10PM CEST, sfel...@cumulusnetworks.com wrote:
>
>On Sep 20, 2014, at 5:51 AM, Roopa Prabhu wrote:
>
>> On 9/20/14, 1:10 AM, Scott Feldman wrote:
>>> On Sep 19, 2014, at 8:41 PM, Roopa Prabhu
>>> wrote:
>>>
>>>
On 9/19/14, 8:49 AM, Jiri Pirko wrote:
> F
On Sep 20, 2014, at 5:51 AM, Roopa Prabhu wrote:
> On 9/20/14, 1:10 AM, Scott Feldman wrote:
>> On Sep 19, 2014, at 8:41 PM, Roopa Prabhu
>> wrote:
>>
>>
>>> On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>>>
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com
wrote:
> On 0
On Fri, Sep 19, 2014 at 04:11:51PM +, Flynn, Dennis R (Dennis) wrote:
> This is our first engagement with the OVS team. We have familiarized
> ourselves with the upstream procedures as defined within the file
> .../CONTRIBUTING and are working to ensure conformance to OVS coding
> standards. We
On 9/20/14, 1:10 AM, Scott Feldman wrote:
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu wrote:
On 9/19/14, 8:49 AM, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using generic Netlink.
Examp
On 9/20/14, 1:09 AM, Jiri Pirko wrote:
Sat, Sep 20, 2014 at 05:41:16AM CEST, ro...@cumulusnetworks.com wrote:
On 9/19/14, 8:49 AM, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using gener
On 09/20/14 07:51, Thomas Graf wrote:
I fail to see the connection. You can use switch vendor SDK no matter
how we define the kernel APIs. They already exist and have been
designed in a way to be completely indepenedent from the kernel.
Are you referring to vendor specific decisions in user spa
On 09/20/14 at 07:32am, Jamal Hadi Salim wrote:
> I am sorry to have tied the two together. Maybe not OVS but the approach
> described is heaven for vendor SDKs.
I fail to see the connection. You can use switch vendor SDK no matter
how we define the kernel APIs. They already exist and have been
de
On 09/20/14 07:01, Thomas Graf wrote:
Nothing speaks against having such a tc classifier. In fact, having
the interface consist of only an embedded Netlink attribute structure
would allow for such a classifier in a very straight forward way.
That doesn't mean everybody should be forced to use t
On 09/20/14 at 06:19am, Jamal Hadi Salim wrote:
> The ovs guys are against this and now no *api exists*?
> Write a 15 tuple classifier tc classifier and use it. I will be more
> than happy to help you. I will get to it when we have basics L2 working
> on real devices.
Nothing speaks against having
On 09/20/14 at 10:14am, Jiri Pirko wrote:
> Sat, Sep 20, 2014 at 12:12:12AM CEST, john.r.fastab...@intel.com wrote:
> >I was considering a slightly different approach where the
> >device would report via netlink the fields/actions it
> >supported rather than creating pre-defined enums for every
> >
On 09/20/14 04:10, Scott Feldman wrote:
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu wrote:
Existing rtnetlink isn’t available to swdev without some kind of snooping the
echoes from the various kernel components
(bridge, fib, etc).
You have made this claim before Scott and I am still not f
On 09/20/14 04:17, Jiri Pirko wrote:
Yes, that I say. It is needed for flow manipulation, because such api does
not exist.
Come on Jiri!
The ovs guys are against this and now no *api exists*?
Write a 15 tuple classifier tc classifier and use it. I will be more
than happy to help you. I will ge
Sat, Sep 20, 2014 at 07:39:51AM CEST, f.faine...@gmail.com wrote:
>On 09/19/14 15:18, Jamal Hadi Salim wrote:
>>On 09/19/14 18:12, John Fastabend wrote:
>>>On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
On 09/19/14 11:49, Jiri Pirko wrote:
>Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojata
Sat, Sep 20, 2014 at 12:18:02AM CEST, j...@mojatatu.com wrote:
>On 09/19/14 18:12, John Fastabend wrote:
>>On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
>>>On 09/19/14 11:49, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
>>>
>Is this just a temporary tes
Sat, Sep 20, 2014 at 12:12:12AM CEST, john.r.fastab...@intel.com wrote:
>On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
>> On 09/19/14 11:49, Jiri Pirko wrote:
>>> Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
>>
Is this just a temporary test tool? Otherwise i dont see reaso
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu wrote:
> On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>> Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
>>> On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using generic Netlink.
Example userspace utility is here
Sat, Sep 20, 2014 at 05:41:16AM CEST, ro...@cumulusnetworks.com wrote:
>On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>>Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
>>>On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using generic Netlink.
Example userspace u
Sat, Sep 20, 2014 at 07:21:00AM CEST, f.faine...@gmail.com wrote:
>On 09/19/14 06:49, Jiri Pirko wrote:
>>Dummy switch implementation using switchdev interface
>
>This really looks like a DSA driver that has 0 ports, and is not attached to
>an useful network interface, and which is registering its
Sat, Sep 20, 2014 at 07:32:08AM CEST, f.faine...@gmail.com wrote:
>On 09/19/14 06:49, Jiri Pirko wrote:
>>This patch adds basic support for flows. The infrastructure is prepared
>>to easily add another flow matching types. So far, only the key one is
>>implemented.
>>
>>Signed-off-by: Jiri Pirko
>
Je m'excuse pour le dérangement, je voudrais faire votre connaissance et
liée une amitié sincère avec vous, prière de me répondre. Je promets
d'être honnête et de garder une bonne relation avec vous.
baisers,
Mlle Patricia Rosa
___
dev mailing list
de
34 matches
Mail list logo
