[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANn89iJxeT6uumtc+2boTGSe7rhsW7GT-cY81t=YaS0QmXJHAQ@mail.gmail.com>
Date: Tue, 1 Nov 2022 21:06:06 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Yunsheng Lin <linyunsheng@...wei.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] ipvlan: minor optimization for ipvlan outbound process
On Tue, Nov 1, 2022 at 8:47 PM Yunsheng Lin <linyunsheng@...wei.com> wrote:
>
> On 2022/11/2 11:23, Eric Dumazet wrote:
> > On Tue, Nov 1, 2022 at 7:15 PM Yunsheng Lin <linyunsheng@...wei.com> wrote:
> >>
> >> Avoid some local variable initialization and remove some
> >> redundant assignment in ipvlan outbound process.
> >>
> >> Signed-off-by: Yunsheng Lin <linyunsheng@...wei.com>
> >
> > Really I do not see the point of such a patch, making future backports
> > more difficult.
>
> As the ipvlan outbound process is in the fast path, avoiding the
> unnecessary steps might be worth the backport cost.
Have you measured the gains after your patch is applied ?
Please give us some numbers, but I bet this will be pure noise,
given the overall ipvlan cost.
>
> Anyway, it is more of judgment call, not a rule, right?
The thing is, you are asking us maintainers/reviewers to spend time on
a non-trivial patch,
with no clear indication of why this is worth our time, and why this
is worth future merge conflicts in backports.
>
> >
> > Changing old code like that should only be done if this is really necessary,
> > for instance before adding a new functionality.
> > .
> >
Powered by blists - more mailing lists