[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <311D4948-8EE4-4A84-A2C4-6B104CEDB81C@nutanix.com>
Date: Thu, 8 May 2025 13:45:42 +0000
From: Jon Kohler <jon@...anix.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
CC: "Michael S. Tsirkin" <mst@...hat.com>, Jason Wang <jasowang@...hat.com>,
Eugenio Pérez <eperezma@...hat.com>,
Alexei Starovoitov
<ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
"David S. Miller"
<davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Jesper Dangaard
Brouer <hawk@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"virtualization@...ts.linux.dev"
<virtualization@...ts.linux.dev>,
"netdev@...r.kernel.org"
<netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: Re: [PATCH net-next] vhost/net: align variable names with XDP
terminology
> On May 8, 2025, at 9:42 AM, Willem de Bruijn <willemdebruijn.kernel@...il.com> wrote:
>
>
> Jon Kohler wrote:
>>
>>
>>> On May 7, 2025, at 1:23 PM, Willem de Bruijn <willemdebruijn.kernel@...il.com> wrote:
>>>
>
> Minor: can you fix email to avoid the above?
I think its a corporate email thing, but good reminder, ill clip it out in future
responses to not pollute the list
>
>>> Jon Kohler wrote:
>>>> Refactor variable names in vhost_net_build_xdp to align with XDP
>>>> terminology, enhancing code clarity and consistency. Additionally,
>>>> reorder variables to follow a reverse Christmas tree structure,
>>>> improving code organization and readability.
>>>>
>>>> This change introduces no functional modifications.
>>>>
>>>> Signed-off-by: Jon Kohler <jon@...anix.com>
>>>
>>> We generally don't do pure refactoring patches.
>>>
>>> They add churn to code history for little gain (and some
>>> overhead and risk).
>>>
>>
>> Ok, I’ll club this together with the larger change I’m working on
>> for multi-buffer support in vhost/net, ill send that as a series
>> when it is ready for eyes
>
> I forgot to add that it makes stable fixes harder to apply across
> LTS, distro and other derived kernels.
>
> So resist the urge the just make stylistic changes. Functional
> improvements warrants the risk, churn and extra work.
>
Fair enough, I think this will make more sense in the context of the
broader series which will end up re-writing the majority of this func.
Was trying to separate some of the prep patches, but I see what
you're saying.
Powered by blists - more mailing lists