Thanks!
On 9/17/14, 3:19 PM, "Jarno Rajahalme" wrote:
>Looks good, thanks again!
>
>Acked-by: Jarno Rajahalme
>
>& pushed to master,
>
> Jarno
>
>On Sep 5, 2014, at 5:10 PM, Daniele Di Proietto
>wrote:
>
>> This optimization is done to avoid calling count_1bits(), which, if the
>>popcnt
>> is
Looks good, thanks again!
Acked-by: Jarno Rajahalme
& pushed to master,
Jarno
On Sep 5, 2014, at 5:10 PM, Daniele Di Proietto wrote:
> This optimization is done to avoid calling count_1bits(), which, if the popcnt
> istruction, is not available might is slow. popcnt may not be available
>
Daniele,
Thanks for the analysis. I did not see that now all miniflows need benefit form
the count.
I’ll send a separate patch just for the NETDEV_KEY_BUF_SIZE_U32 changes.
Jarno
On Sep 11, 2014, at 4:09 PM, Daniele Di Proietto wrote:
> Thanks Jarno,
>
> Your patches look good, unfortunat
Thanks Jarno,
Your patches look good, unfortunately they do not achieve the same
performance enhancements.
By looking at the perf output it appears that we spend a lot of time in
miniflow_extract() storing the miniflow length. I believe this is due to
two reasons:
- Storing the length in the same
Daniele,
I just posted rebased versions of two patches on which I worked earlier in a
similar area as there two patches:
[PATCH 1/2] lib/flow: Add ‘miniflow.count’
[PATCH 2/2] lib/flow: Maintain miniflow values as 64-bit aligned.
I’d like to see if we could generalize the inlining benefits, e.g
This optimization is done to avoid calling count_1bits(), which, if the popcnt
istruction, is not available might is slow. popcnt may not be available
because:
- We are running on old hardware
- (more likely) We're using a generic build (i.e. packaged OVS from a distro),
not tuned for the specif
