[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKgT0Uf969pvLPaE11+PP4RTKiXnvChYSojrirwA1oEYfSLM=g@mail.gmail.com>
Date: Fri, 20 Jul 2018 07:45:01 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: Netdev <netdev@...r.kernel.org>, Jiri Pirko <jiri@...nulli.us>,
Tom Lendacky <thomas.lendacky@....com>,
Florian Fainelli <f.fainelli@...il.com>,
Ariel Elior <ariel.elior@...ium.com>,
Michael Chan <michael.chan@...adcom.com>,
Santosh Raspatur <santosh@...lsio.com>, madalin.bucur@....com,
yisen.zhuang@...wei.com, salil.mehta@...wei.com,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
Tariq Toukan <tariqt@...lanox.com>,
Saeed Mahameed <saeedm@...lanox.com>,
Jiri Pirko <jiri@...lanox.com>,
Ido Schimmel <idosch@...lanox.com>,
Ganesh Goudar <ganeshgr@...lsio.com>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
linux-net-drivers@...arflare.com, peppe.cavallaro@...com,
alexandre.torgue@...com, joabreu@...opsys.com,
grygorii.strashko@...com, Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Subject: Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
On Fri, Jul 20, 2018 at 3:09 AM, Pablo Neira Ayuso <pablo@...filter.org> wrote:
> On Thu, Jul 19, 2018 at 02:04:16PM -0700, Alexander Duyck wrote:
>> On Thu, Jul 19, 2018 at 1:52 PM, Pablo Neira Ayuso <pablo@...filter.org> wrote:
>> > On Thu, Jul 19, 2018 at 08:18:20AM -0700, Alexander Duyck wrote:
>> >> On Wed, Jul 18, 2018 at 5:11 PM, Pablo Neira Ayuso <pablo@...filter.org> wrote:
>> >> > One of the recurring complaints is that we do not have, as a driver
>> >> > writer, a central location from which we would be fed offloading rules
>> >> > into a NIC. This was brought up again during Netconf'18 in Boston.
>> >> >
>> >> > This patch just renames ndo_setup_tc to ndo_setup_offload as a very
>> >> > early initial work to prepare for follow up patch that discuss unified
>> >> > flow representation for the existing offload programming APIs.
>> >> >
>> >> > Signed-off-by: Pablo Neira Ayuso <pablo@...filter.org>
>> >> > Acked-by: Jiri Pirko <jiri@...lanox.com>
>> >> > Acked-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
>> >>
>> >> One request I would have here is to not bother updating the individual
>> >> driver function names. For now I would say we could leave the
>> >> "_setup_tc" in the naming of the driver functions itself and just
>> >> update the name of the net device operation. Renaming the driver
>> >> functions just adds unnecessary overhead and complexity to the patch
>> >> and will make it more difficult to maintain. When we get around to
>> >> adding additional functionality that relates to the rename we could
>> >> address renaming the function on a per driver basis in the future.
>> >
>> > Plan was to follow up patch will rename enum tc_setup_type too:
>> >
>> > https://marc.info/?l=linux-netdev&m=153193158512556&w=2
>> >
>> > that will result in more renames in the driver side.
>> >
>> > I would expect this will happen sooner or later, and out of tree
>> > patches will end up needing a rebase sooner or later, if that is the
>> > concern.
>>
>> I was just thinking that renaming the functions themselves adds noise
>> and makes it harder to debug functions later when they get renamed. As
>> far as the out-of-tree driver I agree we will still have to deal with
>> it due to the enum and NDO function rename. I just figured that using
>> things like LXR is a bit easier when the function name stays the same
>> and you have to move between versions.
>
> Semantic changes in this interface are expected in follow up patches.
> Specifically, this interface will not be exclusively dedicated to 'tc'
> anymore. The function rename will provide a hint on this semantic change
> going on. I understand your concern, and I also tend to dislike renaming
> for the sake of renaming, but in this case this rename coveys useful
> information to developers.
>
> Thanks.
I kind of figured semantic changes were coming. I just thought we
could wait until then for the function renames. There isn't any point
in renaming the function until it changes what it is actually doing. I
suspect you may only have a few drivers that do the update as there
probably isn't much value in updating the function name on drivers
such as fm10k or igb as they are unlikely to ever support anything
other than the tc offloads. That way it is clear that currently none
of the drivers are supporting anything other than the tc offloads
until the new functionality to support netfilter offloads is added on
a per driver basis.
- Alex
Powered by blists - more mailing lists