Message-ID: <CAL+tcoBhNUjWTF1uLnEE3j9mM5T5WAam0CoSuQC69fntb0u7dw@mail.gmail.com>
Date:   Thu, 30 Mar 2023 00:21:02 +0800
From:   Jason Xing <kerneljasonxing@...il.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     Aiden Leong <aiden.leong@...sd.com>, 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 11:36 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> 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.

At first glance, I really don't have any interest in commenting on this.

However, those words 'silly' 'not tested' 'no numbers' make me feel
very uncomfortable. Actually I did all of them. What you said makes
others think I'm like a fool who just does not have any knowledge
about this and proposed one idea with no foundation (out of thin air).
You know that it's not real but I don't know why you're using these
terrible words in public?
In fact, last night in our private email exchange, you said "I need to
be convinced" to me and then it was me who listed nearly every step to
prove how it can have impacts on latency with high load at 3:00 AM.

Well, I wouldn't like to see any further conflicts because of this.
Let's stop here and focus on this patch series and then move on, shall
we?

>
> 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