On Fri, Apr 25, 2014 at 5:47 PM, Joe Stringer wrote:
> Thanks for fixing this, Alex. I think there was a bit of mixup the last
> time I rebased.
>
Np, actually, I will have another patch to add assert (!udpif->handlers &&
!udpif->revalidators)
___
dev m
Thanks for fixing this, Alex. I think there was a bit of mixup the last
time I rebased.
On 26 April 2014 07:33, Alex Wang wrote:
> Applied, thx a lot,
>
> Now, let's fix the build (unittest) issue~~~
>
>
> On Fri, Apr 25, 2014 at 11:31 AM, Gurucharan Shetty wrote:
>
>> On Fri, Apr 25, 2014 at 1
Signed-off-by: Pritesh Kothari
---
v5: move skb_clear_rxhash() from compat.h to skbuff.h,
simplify skb_get_hash() integration,
fix random.h order in acinclude.m4,
move pcpu_sw_netstats to netdevice.h.
v4: rebase for changes in datapath/actions.c and datapath/vport.c,
split patch in
Acked-by: Alex Wang
And applied,
On Fri, Apr 25, 2014 at 3:12 PM, Alex Wang wrote:
> It is even harder to reproduce the new failure, rarer than the flow-dumps
> one. Just ran into this once in my life...
>
> More importantly, the flow-dumps pkt counts are sync'ed in the failed case.
>
> Fro
It is even harder to reproduce the new failure, rarer than the flow-dumps
one. Just ran into this once in my life...
More importantly, the flow-dumps pkt counts are sync'ed in the failed case.
>From my understanding, this new issue, relates to reading stats from
netdev-dummy, which is different
Hi Jesse,
2014-04-25, Jesse Gross:
>> Practically speaking, making your layer 3 port code work for
>> MPLS-over-GRE is not entirely trivial:
>> - on emission, compose_output_action__ pops the Ethernet header before
>> push_mpls is called (which is done during commit_odp_actions) ; this
>> does not
On Fri, Apr 11, 2014 at 4:29 PM, Jarno Rajahalme wrote:
> Key attributes relating to actual packet headers are ignored for
> OVS_PACKET_CMD_EXECUTE as the header key attributes are retrieved
> from the packet itself.
>
> Signed-off-by: Jarno Rajahalme
Acked-by: Jesse Gross
_
On Fri, Apr 11, 2014 at 4:29 PM, Jarno Rajahalme wrote:
> In general, all Netlink 64-bit data may be 4-byte aligned, due to
> netlink header and attributes being 4-aligned.
>
> To avoid unaligned access the data should be copied out of the netlink
> attribute before access.
>
> Signed-off-by: Jarn
On Thu, Apr 17, 2014 at 2:54 AM, wrote:
> Hi Lori, all,
>
> While I've attempted to adapt the layer 3 port patch to GRE tunneling,
> and obtained nice results for IP-over-GRE (as I reported last week),
> I've had a harder time reusing this framework for -over-GRE, in
> particular for MPLS-over-GR
On Apr 25, 2014, at 12:36 PM, Jesse Gross wrote:
> On Fri, Apr 25, 2014 at 12:16 PM, Pritesh Kothari (pritkoth)
> wrote:
>> Hi Jesse,
>>
diff --git a/datapath/linux/compat/include/linux/etherdevice.h
b/datapath/linux/compat/include/linux/etherdevice.h
index 556729d..c6e8e
On Fri, Apr 25, 2014 at 1:06 AM, YAMAMOTO Takashi
wrote:
>> On Thu, Apr 24, 2014 at 05:57:29PM +0900, YAMAMOTO Takashi wrote:
>>> hi,
>>>
>>> > + * Due to the sample action there may be multiple possible eth types.
>>> > + * In order to correctly validate actions all possible types are tracked
>>>
Jarno and I just talked and agreed that it's probably finally time to
introduce some capabilities attributes. This would allow us to avoid
probing altogether and therefore avoid the logging issues.
On Fri, Apr 25, 2014 at 11:59 AM, Andy Zhou wrote:
> How about we skip logging each unexpected key
On Fri, Apr 25, 2014 at 12:16 PM, Pritesh Kothari (pritkoth)
wrote:
> Hi Jesse,
>
>>>
>>> diff --git a/datapath/linux/compat/include/linux/etherdevice.h
>>> b/datapath/linux/compat/include/linux/etherdevice.h
>>> index 556729d..c6e8e92 100644
>>> --- a/datapath/linux/compat/include/linux/etherdev
Applied, thx a lot,
Now, let's fix the build (unittest) issue~~~
On Fri, Apr 25, 2014 at 11:31 AM, Gurucharan Shetty wrote:
> On Fri, Apr 25, 2014 at 11:04 AM, Alex Wang wrote:
> > Commit 7d170098 (ofproto-dpif-upcall: Remove the flow_dumper thread.)
> > initialized the memory barrier inside t
Hi Jesse,
>>
>> diff --git a/datapath/linux/compat/include/linux/etherdevice.h
>> b/datapath/linux/compat/include/linux/etherdevice.h
>> index 556729d..c6e8e92 100644
>> --- a/datapath/linux/compat/include/linux/etherdevice.h
>> +++ b/datapath/linux/compat/include/linux/etherdevice.h
>> @@ -34,6
How about we skip logging each unexpected key attributes once? We can
use a u64 bit fields to keep track the flow key attributes in the
kernel module.
On Thu, Apr 24, 2014 at 6:30 PM, Jesse Gross wrote:
> On Thu, Apr 24, 2014 at 4:30 PM, Jarno Rajahalme
> wrote:
>>
>> On Apr 24, 2014, at 3:32
Looks great. Thanks!
On Fri, Apr 25, 2014 at 9:56 AM, Ben Pfaff wrote:
> If 'lacp' is NULL, then lacp_create() might not have been called to
> indirectly initialize the mutex via lacp_init(), so call lacp_init()
> from lacp_status().
>
> Signed-off-by: Ben Pfaff
> Acked-by: Andy Zhou
> ---
> l
On Fri, Apr 25, 2014 at 11:04 AM, Alex Wang wrote:
> Commit 7d170098 (ofproto-dpif-upcall: Remove the flow_dumper thread.)
> initialized the memory barrier inside the udpif_start_threads() function.
> However, the udpif_start_threads() function does not check the number of
> revalidator threads sp
On Fri, Apr 25, 2014 at 01:40:13PM +0900, Simon Horman wrote:
> I'd like to clarify the status of this series.
>
> I believe that as it stands it is ready for review.
> And that the dependencies I list above only affect the reliability
> of tests added in the last patch of the series: they address
Interested candidates should forward their resumes/CV (Specifying position of
interest) with verifiable reference(s) as word attached document to E-Mail:
jobcare...@shqiptar.eu
Yours SincerelyShqiptar Recruitment Agency___
dev mailing list
dev@openvs
Commit 7d170098 (ofproto-dpif-upcall: Remove the flow_dumper thread.)
initialized the memory barrier inside the udpif_start_threads() function.
However, the udpif_start_threads() function does not check the number of
revalidator threads specified in udpif. So, when the number is zero, it
causes th
The test added in this commit would have caught the bug fixed by commit
96be8de595150 (bridge: When ports disappear from a datapath, add them
back.). With that commit reverted, the new test fails.
Signed-off-by: Ben Pfaff
---
lib/dpif-netdev.c | 61 ---
Found the bug, i introduced it, so sorry,
On Fri, Apr 25, 2014 at 9:45 AM, Gurucharan Shetty wrote:
> Alex wanted the backtrace:
> at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x76d13bab in __GI_abort () at abort.c:91
> #2 0x004f08b0 in ovs_abort_valist (err_no=22,
>
On Fri, Apr 25, 2014 at 08:50:10AM -0700, Gurucharan Shetty wrote:
> On Fri, Apr 25, 2014 at 8:46 AM, Ben Pfaff wrote:
> > On Thu, Apr 24, 2014 at 11:27:47PM -0700, Andy Zhou wrote:
> >> The logic looks good. 233 unit tests failed now. Apparently this
> >> patch is great doing a great job on catc
v1->v2: In patch 1, always initialize the lacp mutex, instead of avoiding
the need to initialize it.
Ben Pfaff (2):
lacp: Ensure that mutex is initialized when used in lacp_status().
ovs-thread: Add checking for mutex and rwlock initialization.
lib/lacp.c | 18 +++---
These should have been marked v2. Sorry.
On Fri, Apr 25, 2014 at 09:56:22AM -0700, Ben Pfaff wrote:
> v1->v2: In patch 1, always initialize the lacp mutex, instead of avoiding
>the need to initialize it.
>
> Ben Pfaff (2):
> lacp: Ensure that mutex is initialized when used in lacp_status()
With glibc, a mutex or rwlock filled with all-zero-bytes is properly
initialized for use, but this is not true for any other libc that OVS
supports. However, OVS gets a lot more testing with glibc than any other
libc. This means that developers keep introducing bugs that do not
manifest on the ma
If 'lacp' is NULL, then lacp_create() might not have been called to
indirectly initialize the mutex via lacp_init(), so call lacp_init()
from lacp_status().
Signed-off-by: Ben Pfaff
Acked-by: Andy Zhou
---
lib/lacp.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
d
Alex wanted the backtrace:
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x76d13bab in __GI_abort () at abort.c:91
#2 0x004f08b0 in ovs_abort_valist (err_no=22,
format=0x55714f "%s failed", args=0x7fffdf58) at lib/util.c:306
#3 0x004f0883 in ovs_abort (err_
With this patch, ovs-vswitchd now crashes with the following error
during upgrades.
ovs-vswitchd: pthread_barrier_init failed (Invalid argument)
ovs-vswitchd: fork child died before signaling startup (killed
(Aborted), core dumped)
Note that this happens when ovs-vswitchd is started with:
other_c
Allocate struct rule_actions and the space for the actions at once.
This reduces one memory indirection and helps reduce cache misses
visible in perf annotations.
Fix some old comments referring to ref count, since we now use RCU for
this.
Enforce constness of the actions throughout the code.
Si
On Fri, Apr 25, 2014 at 8:46 AM, Ben Pfaff wrote:
> On Thu, Apr 24, 2014 at 11:27:47PM -0700, Andy Zhou wrote:
>> The logic looks good. 233 unit tests failed now. Apparently this
>> patch is great doing a great job on catching uninitialized mutex and
>> rwlocks.
>>
>> Assume the tests will be fix
On Thu, Apr 24, 2014 at 11:27:47PM -0700, Andy Zhou wrote:
> The logic looks good. 233 unit tests failed now. Apparently this
> patch is great doing a great job on catching uninitialized mutex and
> rwlocks.
>
> Assume the tests will be fixed before checking in:
I did my testing with one of Guru
On Thu, Apr 24, 2014 at 11:03:16PM -0700, Andy Zhou wrote:
> Acked-by: Andy Zhou
>
> With a question inline.
>
>
> On Thu, Apr 24, 2014 at 4:59 PM, Ben Pfaff wrote:
> > If the 'lacp' parameter is nonnull, then we know that the file scope mutex
> > has been initialized, since that's done as a s
found this in the morning, will keep investigating,
./learn.at:362: (ovs-ofctl dump-ports br0 2; ovs-ofctl dump-ports br0 3) |
sed 's/ (xid=0x[0-9a-fA-F]*)//'
--- - 2014-04-25 01:25:43.022048477 -0700
+++ /root/openvswitch/tests/testsuite.dir/at-groups/328/stdout 2014-04-25
01:25:43.01771189
Hi Jesse,
(inlined below)
Jesse Gross :
>>
>> In general, I think it would be a good idea for the flow key to
>> have
>> a
>> field
>> specifying the layer 3 protocol, when an ethernet header is not
>> present.
>
> That makes
On 4/25/14, 5:19 AM, Jesse Gross wrote:
+noethernet:
if (nla_put_be16(skb, OVS_KEY_ATTR_ETHERTYPE,
output->eth.type))
goto nla_put_failure;
Does it still make sense to send the EtherType? It's not present in
the packet and I believe that the information is contain
> On Thu, Apr 24, 2014 at 05:57:29PM +0900, YAMAMOTO Takashi wrote:
>> hi,
>>
>> > + * Due to the sample action there may be multiple possible eth types.
>> > + * In order to correctly validate actions all possible types are tracked
>> > + * and verified. This is done using struct eth_types.
>>
>
Simon, I thought this test exposed a bug that is fixed with this
patch series. However, when I apply this patch alone against current
master, it passed fine. (I tried many times). So I must
misunderstand the intention of the test, or why current master failed
to address
packet out. Would you p
39 matches
Mail list logo
