[dpdk-dev] spinlock: Move constructor function out of header file

Damjan Marion (damarion) damarion at cisco.com
Fri Jul 15 11:54:44 CEST 2016


> On 15 Jul 2016, at 10:31, Thomas Monjalon <thomas.monjalon at 6wind.com> wrote:
> 
> 2016-07-14 22:20, Damjan Marion:
>> 
>>> On 15 Jul 2016, at 00:06, Thomas Monjalon <thomas.monjalon at 6wind.com> wrote:
>>> 
>>> 2016-07-14 18:10, Damjan Marion:
>>>> Dear Jan,
>>>> 
>>>> Thank you for your comments. A bit too much overhead to submit simple patch
>>>> so let’s forget about it. I will just add it as it is to our private
>>>> collection of patches.
>>> 
>>> These are changes trivial to fix when applying.
>>> I strongly prefer that you upstream patches instead of keeping patches
>>> in the VPP repository. I will help you in this task.
>>> Thanks for the effort.
>> 
>> Yeah, I agree with you, unfortunately it is all about time,
>> for me it is still cheaper to rebase them.
>> 
>> I respect your rules, but I just don’t have enough free cycles
>> to spend learning all of them, for my occasional patch submission.
> 
> We know there is a learning curve for the submission process.
> That's why we do not expect it to be fully satisfied, especially
> from occasional contributors.
> I am used to do some not significant changes before applying to
> help newcomers patches being accepted. That's what I will do in
> your case.
> As I said previously I will help you to drop your local patches.
> 
> Please continue sending other patches with a detailed explanation
> and we will take care of them.

Ok, Thanks!

So we don’t have much pending beside 2 patches for i40e which 
Jeff submitted yesterday and they will i guess need to wait for 16.11.

Only one which I have on my mind is:

https://git.fd.io/cgit/vpp/tree/dpdk/dpdk-16.04_patches/0005-Allow-applications-to-override-rte_delay_us.patch

This is big issue for us when running single-core, as some
drivers tend to call rte_delay_us for a long time, and that is 
causing packet drops. I.e. if you do stop/start on one interface
and you are running BFD on another one, BFD will fail…

Current patch is hack, it basically allows us to override 
delay function so we can de-schedule it,
do some other useful work while waiting for delay to finish
and then give control back to original function…

Maybe we can fix this by providing a delay callback functionality...

Thanks,

Damjan




More information about the dev mailing list