Hi Alex,
On 04/22/2014 09:31 PM, Alexandru Copot wrote:
+/* List of 'struct bundle_message's */
+struct list msg_list;
+struct ovs_mutex list_mutex;
I think we can remove this mutex too.
Daniel.
___
dev mailing list
dev@openvswitch
Jarno Rajahalme wrote:
Daniele, Martino,
Thank you for the contribution, and sorry that it has taken so long for me to
get to the review!
Thank you for the thorough revision.
We are going to take a deeper look at it and provide modifications/comments.
B.R., Martino.
__
On Tue, Apr 22, 2014 at 08:18:04PM +0100, Ben Hutchings wrote:
> From: Zoltan Kiss
>
> commit 36d5fe6a000790f56039afe26834265db0a3ad4c upstream.
>
> skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
> orphan them. Also, it doesn't handle errors, so this patch takes c
This is only the communication part of the bundles functionality.
The actual message pre-validation and commits are not implemented.
Signed-off-by: Alexandru Copot
---
v4:
* adjust copyright
* fix style issues
* remove all locking
* delete bundles in ofconn_destroy()
v3:
* rebase
* ad
On 22/04/14 20:18, Ben Hutchings wrote:
From: Zoltan Kiss
commit 36d5fe6a000790f56039afe26834265db0a3ad4c upstream.
skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care of that
as well, and modify t
On 22/04/14 22:39, Ben Pfaff wrote:
On Tue, Apr 22, 2014 at 06:27:18PM +0100, Zoltan Kiss wrote:
This function returns true when 's' is negative or greater than UINT_MAX. Also,
the representation of 'int' and 'unsigned int' is implementation dependent, so
converting [INT_MAX..UINT_MAX] values wi
On Tue, Apr 22, 2014 at 3:18 PM, Ben Hutchings wrote:
> From: Zoltan Kiss
>
> commit 36d5fe6a000790f56039afe26834265db0a3ad4c upstream.
>
> skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
> orphan them. Also, it doesn't handle errors, so this patch takes care of tha
This function returns true when 's' is negative or greater than UINT_MAX. Also,
the representation of 'int' and 'unsigned int' is implementation dependent, so
converting [INT_MAX..UINT_MAX] values with str_to_int is fragile.
Instead, we should convert straight to 'long long' and do a boundary check
On Tue, Apr 22, 2014 at 2:58 PM, Ben Pfaff wrote:
> On Tue, Apr 22, 2014 at 01:40:55PM -0700, Gurucharan Shetty wrote:
>> > Should OVS chdir to the root (on all drives?) on Windows
>> > also?
>> Looks like chdir("/") on windows takes me to C:/ . So doing that on
>> windows should be good. I will r
mask caches index of mask in mask_list. On packet recv OVS
need to traverse mask-list to get cached mask. Therefore array
is better for retrieving cached mask. This also allows better
cache replacement algorithm by directly checking mask's existence.
Signed-off-by: Pravin B Shelar
---
datapat
Along with flow-table rehashing OVS can compact masks array. This
allows us to calculate highest index for mask array.
Signed-off-by: Pravin B Shelar
---
datapath/flow_table.c | 24
datapath/flow_table.h |2 +-
2 files changed, 21 insertions(+), 5 deletions(-)
di
On every packet OVS needs to lookup flow-table with every mask
until it finds a match. The packet flow-key is first masked
with mask in the list and then the masked key is looked up in
flow-table. Therefore number of masks can affect packet
processing performance.
Following patch adds mask index
Ths simplifies flow-table-destroy API. This change is required
for following patches.
Signed-off-by: Pravin B Shelar
---
Added comment
---
datapath/datapath.c |5 ++---
datapath/flow_table.c |8 +---
datapath/flow_table.h |2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
On Wed, Apr 23, 2014 at 8:47 AM, Gurucharan Shetty wrote:
> On Tue, Apr 22, 2014 at 2:58 PM, Ben Pfaff wrote:
>> On Tue, Apr 22, 2014 at 01:40:55PM -0700, Gurucharan Shetty wrote:
>>> > Should OVS chdir to the root (on all drives?) on Windows
>>> > also?
>>> Looks like chdir("/") on windows takes
On Wed, Apr 23, 2014 at 02:06:12PM +0900, Simon Horman wrote:
> My understanding of the implementation of patch ports is that they
> are rather special, being handled as a special case inside
> compose_output_action__() and do not exist in the datapath.
>
> A side effect of the implementation of p
On Tue, Apr 22, 2014 at 10:24 PM, Alex Wang wrote:
> diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
>> index 416cfdc..906bf17 100644
>> --- a/ofproto/ofproto-dpif-upcall.c
>> +++ b/ofproto/ofproto-dpif-upcall.c
>> @@ -45,6 +45,8 @@
>>
>> VLOG_DEFINE_THIS_MODULE(ofprot
On Tue, Apr 22, 2014 at 04:54:24PM +1200, Joe Stringer wrote:
> From: Ethan Jackson
>
> Previously, we had a separate flow_dumper thread that fetched flows from
> the datapath to distribute to revalidator threads. This patch takes the
> logic for dumping and pushes it into the revalidator threads
On Wed, Apr 23, 2014 at 02:45:21PM +0100, Zoltan Kiss wrote:
> This function returns true when 's' is negative or greater than UINT_MAX.
> Also,
> the representation of 'int' and 'unsigned int' is implementation dependent, so
> converting [INT_MAX..UINT_MAX] values with str_to_int is fragile.
> In
Hi,
I would like to ask, what's the status of enabling Netlink MMAP in the
userspace? I'm interested to see this progressing, but digging the mail
archive I've found it run into scalability issues:
http://openvswitch.org/pipermail/dev/2013-December/034546.html
And also it can't handle frags
The problem has actually gotten worse since we've gotten rid of the
dispatcher thread. Now each thread has it's own channel per port.
I wonder if the right approach is to simply ditch the per-port
fairness in the case where mmap netlink is enabled. I.E. we simply
have one channel per thread and
This patch improves the code readability and comments on the
recirculation related changes to rule_dpif_lookup() base on off-line
discussions with Jarno. There is no behavior changes.
Signed-off-by: Andy Zhou
---
ofproto/ofproto-dpif.c | 21 ++---
1 file changed, 14 insertions(+
Acked-by: Ethan Jackson
On Wed, Apr 23, 2014 at 1:26 PM, Andy Zhou wrote:
> This patch improves the code readability and comments on the
> recirculation related changes to rule_dpif_lookup() base on off-line
> discussions with Jarno. There is no behavior changes.
>
> Signed-off-by: Andy Zhou
On 04/23/2014 10:12 PM, Ethan Jackson wrote:
The problem has actually gotten worse since we've gotten rid of the
dispatcher thread. Now each thread has it's own channel per port.
I wonder if the right approach is to simply ditch the per-port
fairness in the case where mmap netlink is enabled.
On 04/23/2014 05:49 PM, Pravin B Shelar wrote:
Ths simplifies flow-table-destroy API. This change is required
for following patches.
Signed-off-by: Pravin B Shelar
Thanks for adding the comment.
Acked-by: Thomas Graf
___
dev mailing list
dev@open
On 04/23/2014 05:49 PM, Pravin B Shelar wrote:
On every packet OVS needs to lookup flow-table with every mask
until it finds a match. The packet flow-key is first masked
with mask in the list and then the masked key is looked up in
flow-table. Therefore number of masks can affect packet
processi
On 04/23/2014 05:49 PM, Pravin B Shelar wrote:
mask caches index of mask in mask_list. On packet recv OVS
need to traverse mask-list to get cached mask. Therefore array
is better for retrieving cached mask. This also allows better
cache replacement algorithm by directly checking mask's existen
On 04/23/2014 05:49 PM, Pravin B Shelar wrote:
Along with flow-table rehashing OVS can compact masks array. This
allows us to calculate highest index for mask array.
Signed-off-by: Pravin B Shelar
Looks great in general, see comment below.
---
datapath/flow_table.c | 24 +++
Pushed. Thanks for the review.
On Wed, Apr 23, 2014 at 2:30 PM, Ethan Jackson wrote:
> Acked-by: Ethan Jackson
>
>
> On Wed, Apr 23, 2014 at 1:26 PM, Andy Zhou wrote:
>> This patch improves the code readability and comments on the
>> recirculation related changes to rule_dpif_lookup() base on o
On 24 April 2014 04:56, Alex Wang wrote:
>
> On Tue, Apr 22, 2014 at 10:24 PM, Alex Wang wrote:
>
>> diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
>>> index 416cfdc..906bf17 100644
>>> --- a/ofproto/ofproto-dpif-upcall.c
>>> +++ b/ofproto/ofproto-dpif-upcall.c
>>> @@
This allows rules to be used without taking references while RCU
protected.
The last step of destroying an ofproto also needs to be postponed, as
the rule destruction requires the class structure to be available at
the postponed destruction callback.
Signed-off-by: Jarno Rajahalme
---
ofproto/o
Prior to this paths the rule lookup functions have always taken a
reference on the found rule before returning. Make this conditional,
so that unnecessary refs/unrefs can be avoided in a later patch.
Signed-off-by: Jarno Rajahalme
---
ofproto/ofproto-dpif-xlate.c |8 +++---
ofproto/ofproto-
Only take reference to a looked up rule when needed.
This reduces the total CPU utilization of rule_ref/unref calls by 80%,
from 5% of total server CPU capacity to 1% in a netperf TCP_CRR
test stressing the userspace.
Signed-off-by: Jarno Rajahalme
---
ofproto/ofproto-dpif-xlate.c | 49 ++
Acked-by: Ethan Jackson
On Wed, Apr 23, 2014 at 4:20 PM, Jarno Rajahalme wrote:
> This allows rules to be used without taking references while RCU
> protected.
>
> The last step of destroying an ofproto also needs to be postponed, as
> the rule destruction requires the class structure to be ava
Traditionally we've put function comments just in the .c file, not in
the .c and .h file as you've done for rule_dpif_lookup(). That said,
I don't know where that convention came from and don't care that much
. . .
Acked-by: Ethan Jackson
On Wed, Apr 23, 2014 at 4:20 PM, Jarno Rajahalme wrote
LGTM
Acked-by: Ethan Jackson
On Wed, Apr 23, 2014 at 4:20 PM, Jarno Rajahalme wrote:
> Only take reference to a looked up rule when needed.
>
> This reduces the total CPU utilization of rule_ref/unref calls by 80%,
> from 5% of total server CPU capacity to 1% in a netperf TCP_CRR
> test stress
Before commit 2a73b1d73d4bdb (bridge: Reconfigure in single pass.), if a
port disappeared, for one reason or another, from a datapath, the next
bridge reconfiguration pass would notice and, if the port was still
configured in the database, add the port back to the datapath. That
commit, however, r
On Wed, Apr 23, 2014 at 09:36:30AM -0700, Ben Pfaff wrote:
> On Wed, Apr 23, 2014 at 02:06:12PM +0900, Simon Horman wrote:
> > My understanding of the implementation of patch ports is that they
> > are rather special, being handled as a special case inside
> > compose_output_action__() and do not e
Pushed to master and branch-2.1.
On 24 April 2014 11:06, Joe Stringer wrote:
> On 24 April 2014 04:56, Alex Wang wrote:
>
>>
>> On Tue, Apr 22, 2014 at 10:24 PM, Alex Wang wrote:
>>
>>> diff --git a/ofproto/ofproto-dpif-upcall.c
b/ofproto/ofproto-dpif-upcall.c
index 416cfdc..906bf17
Thanks for taking care of this.
Acked-by: Ethan Jackson
On Wed, Apr 23, 2014 at 5:06 PM, Ben Pfaff wrote:
> Before commit 2a73b1d73d4bdb (bridge: Reconfigure in single pass.), if a
> port disappeared, for one reason or another, from a datapath, the next
> bridge reconfiguration pass would noti
Thanks, I applied this to master and branch-2.1.
On Wed, Apr 23, 2014 at 05:27:02PM -0700, Ethan Jackson wrote:
> Thanks for taking care of this.
>
> Acked-by: Ethan Jackson
>
>
> On Wed, Apr 23, 2014 at 5:06 PM, Ben Pfaff wrote:
> > Before commit 2a73b1d73d4bdb (bridge: Reconfigure in single
Thanks, I tidied up the comments, added threadsafety annotations for xcache
and pushed.
On 24 April 2014 06:38, Ben Pfaff wrote:
> On Tue, Apr 22, 2014 at 04:54:24PM +1200, Joe Stringer wrote:
> > From: Ethan Jackson
> >
> > Previously, we had a separate flow_dumper thread that fetched flows f
W00t, nice to see this in.
Ethan
On Wed, Apr 23, 2014 at 9:32 PM, Joe Stringer wrote:
> Thanks, I tidied up the comments, added threadsafety annotations for xcache
> and pushed.
>
>
> On 24 April 2014 06:38, Ben Pfaff wrote:
>>
>> On Tue, Apr 22, 2014 at 04:54:24PM +1200, Joe Stringer wrote:
>>
42 matches
Mail list logo
