> 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
