Message-ID: <CANn89iJsYLrvjms-uT0mLPiiLG-MtHMSm3dSy6QDqP0d46mSJg@mail.gmail.com>
Date:   Wed, 29 Mar 2023 17:33:10 +0200
From:   Eric Dumazet <edumazet@...gle.com>
To:     Aiden Leong <aiden.leong@...sd.com>
Cc:     davem@...emloft.net, eric.dumazet@...il.com,
        kernelxing@...cent.com, kuba@...nel.org, netdev@...r.kernel.org,
        pabeni@...hat.com
Subject: Re: [PATCH net-next 0/4] net: rps/rfs improvements

On Wed, Mar 29, 2023 at 3:18 PM Aiden Leong <aiden.leong@...sd.com> wrote:
>
> On Wednesday, March 29, 2023 9:17:06 PM CST Aiden Leong wrote:
> > Hi Eric,
> >
> > I hope my email is not too off-topic but I have some confusion on how
> > maintainers and should react to other people's work.
> >
> > In short, you are stealing Jason's idea&&work by rewriting your
> > implementation which not that ethical. Since your patch is based on his
> > work, but you only sign-off it by your name, it's possible to raise lawsuit
> > between Tencent and Linux community or Google.

Seriously ?

I really gave enough credit to Jason's work, it seems you missed it.

I am quite tired of reviewing patches, and giving ideas of how to
improve things,
then having no credits for my work.

After my feedback on v1, seeing a quite silly v2, obviously not tested,
and with no numbers shown, I wanted to see how hard the complete
implementation would be.

This needed full understanding of RPS and RFS, not only an "idea" and
wrong claims about fixing
a "bug" in the initial implementation which was just fine.

Also, results are theoretical at this stage,I added numbers in the cover letter
showing the impact was tiny or not even mesurable.

I sent a series of 4 patches, Jason work on the 3rd one has been
completely documented.

If Jason managers are not able to see the credit in the patch series
(and cover letter),
this is their problem, not mine.

Also, my contributions to linux do not represent views of my employer,
this should be obvious.



> >
> > I'm here to provoke a conflict because we know your name in this area and
> > I'd to show my respect to you but I do have this kind of confusion in my
> > mind and wish you could explain about it.
> >
> Typo: I'm here NOT to provoke a conflict
> > There's another story you or Tom Herbert may be interested in: I was working
> > on Foo Over UDP and have implemented the missing features in the previous
> > company I worked for. The proposal to contribute to the upstream community
> > was rejected later by our boss for unhappy events very similar to this one.
> >
> > Aiden Leong
> >
> > > Jason Xing attempted to optimize napi_schedule_rps() by avoiding
> > > unneeded NET_RX_SOFTIRQ raises: [1], [2]
> > >
> > > This is quite complex to implement properly. I chose to implement
> > > the idea, and added a similar optimization in ____napi_schedule()
> > >
> > > Overall, in an intensive RPC workload, with 32 TX/RX queues with RFS
> > > I was able to observe a ~10% reduction of NET_RX_SOFTIRQ
> > > invocations.
> > >
> > > While this had no impact on throughput or cpu costs on this synthetic
> > > benchmark, we know that firing NET_RX_SOFTIRQ from softirq handler
> > > can force __do_softirq() to wakeup ksoftirqd when need_resched() is true.
> > > This can have a latency impact on stressed hosts.
> > >
> > > [1] https://lore.kernel.org/lkml/20230325152417.5403-1->
> >
> > kerneljasonxing@...il.com/
> >
> > > [2]
> > > https://lore.kernel.org/netdev/20230328142112.12493-1-kerneljasonxing@gma
> > > il.com/>
> > > Eric Dumazet (4):
> > >   net: napi_schedule_rps() cleanup
> > >   net: add softnet_data.in_net_rx_action
> > >   net: optimize napi_schedule_rps()
> > >   net: optimize ____napi_schedule() to avoid extra NET_RX_SOFTIRQ
> > >
> > >  include/linux/netdevice.h |  1 +
> > >  net/core/dev.c            | 46 ++++++++++++++++++++++++++++++---------
> > >  2 files changed, 37 insertions(+), 10 deletions(-)
>

Powered by blists - more mailing lists