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 <pa...@netfilter.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 <pa...@netfilter.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 <pa...@netfilter.org> > >> > Acked-by: Jiri Pirko <j...@mellanox.com> > >> > Acked-by: Jakub Kicinski <jakub.kicin...@netronome.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.