Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
From: Daniel Borkmann Date: Fri, 20 Jul 2018 19:28:23 +0200 > This might be fine as new ndo depending on the use case this will have (?), > but fwiw the term 'flow' or 'rule' would be misleading for what tc offload > would be doing today (e.g. to name one, there's no notion of 'flow' in BPF > offload). Given today this interface is deeply baked into tc, just a rename > might not suffice but should probably move the whole handling around it such > as assembling the offload info into generic net/core/netdev.c as well if this > is the way to go. I would much rather see a new NDO for handling a new offload. That is consistent with our overall game plan of the past few years ever since this TC offload NDO went in. We can't pretend to be able to predict the future and know that these various things can be consolidated into a single interface beforehand. It is important to see what implementing a new offload looks like, in a couple of drivers, first. And then we can have something to look at, and discuss, with respect to NDO consolidation. What is happening with this patch is you are brute force making this NDO generic, and then saying "I will show you how it can be generic." Sorry, that's the wrong way around. Make a new NDO op for your flow offloading, show how it works and is implemented in a few drivers, and then (and only then) can you talk about whether consolidating is possible or appropriate. Thank you.
Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
On 07/20/2018 04:37 PM, Roopa Prabhu wrote: > On Wed, Jul 18, 2018 at 5:11 PM, Pablo Neira Ayuso > 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 >> Acked-by: Jiri Pirko >> Acked-by: Jakub Kicinski > > ok with a rename,...but this seems to be going from a very specific to > a completely generic name. > maybe ndo_setup_flow_offload or ndo_setup_rule_offload might be better ?. This might be fine as new ndo depending on the use case this will have (?), but fwiw the term 'flow' or 'rule' would be misleading for what tc offload would be doing today (e.g. to name one, there's no notion of 'flow' in BPF offload). Given today this interface is deeply baked into tc, just a rename might not suffice but should probably move the whole handling around it such as assembling the offload info into generic net/core/netdev.c as well if this is the way to go. > (or maybe i am missing some context and this is really for setting up > every possible hardware offload ?)
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 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 >> 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 >> >> 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 >> >> > Acked-by: Jiri Pirko >> >> > Acked-by: Jakub Kicinski >> >> >> >> 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=153193158512556=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
Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
On Wed, Jul 18, 2018 at 5:11 PM, Pablo Neira Ayuso 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
> Acked-by: Jiri Pirko
> Acked-by: Jakub Kicinski
ok with a rename,...but this seems to be going from a very specific to
a completely generic name.
maybe ndo_setup_flow_offload or ndo_setup_rule_offload might be better ?.
(or maybe i am missing some context and this is really for setting up
every possible hardware offload ?)
> ---
> v2: Missing function definition update in drivers/net/ethernet/sfc/falcon/tx.c
> apparently I forgot to turn on that driver when doing compile-testing,
> problem spotted by Martin Habets. Keeping Jakub and Jiri Acked-by tags,
> as this is the only change in the v1 patch.
>
> drivers/net/ethernet/amd/xgbe/xgbe-drv.c| 6 +++---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 6 +++---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 4 ++--
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c| 2 +-
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 6 +++---
> drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c | 6 +++---
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 6 +++---
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 6 +++---
> drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 +++---
> drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 6 +++---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 6 +++---
> drivers/net/ethernet/intel/i40evf/i40evf_main.c | 8
> drivers/net/ethernet/intel/igb/igb_main.c | 6 +++---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +++---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 9 +
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 6 +++---
> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c| 6 +++---
> drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 6 +++---
> drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 2 +-
> drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 2 +-
> drivers/net/ethernet/netronome/nfp/nfp_port.c | 4 ++--
> drivers/net/ethernet/netronome/nfp/nfp_port.h | 4 ++--
> drivers/net/ethernet/sfc/efx.c | 2 +-
> drivers/net/ethernet/sfc/efx.h | 4 ++--
> drivers/net/ethernet/sfc/falcon/efx.c | 2 +-
> drivers/net/ethernet/sfc/falcon/efx.h | 4 ++--
> drivers/net/ethernet/sfc/falcon/tx.c| 4 ++--
> drivers/net/ethernet/sfc/tx.c | 4 ++--
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
> drivers/net/ethernet/ti/netcp_core.c| 6 +++---
> drivers/net/netdevsim/netdev.c | 5 +++--
> include/linux/netdevice.h | 18 +-
> net/dsa/slave.c | 7 ---
> net/sched/cls_api.c | 6 +++---
> net/sched/sch_cbs.c | 8
> net/sched/sch_etf.c | 8
> net/sched/sch_mq.c | 8
> net/sched/sch_mqprio.c | 16
> net/sched/sch_prio.c| 15 ---
> net/sched/sch_red.c | 15 ---
> 40 files changed, 131 insertions(+), 126 deletions(-)
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
> b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
> index 24f1053b8785..766864a35648 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
> @@ -2246,8 +2246,8 @@ static void xgbe_poll_controller(struct net_device
> *netdev)
> }
> #endif /* End CONFIG_NET_POLL_CONTROLLER */
>
> -static int xgbe_setup_tc(struct net_device *netdev, enum tc_setup_type type,
> -void *type_data)
> +static int xgbe_setup_offload(struct net_device *netdev,
> + enum tc_setup_type type, void *type_data)
> {
> struct xgbe_prv_data *pdata = netdev_priv(netdev);
> struct tc_mqprio_qopt *mqprio = type_data;
> @@ -2501,7 +2501,7 @@ static const struct net_device_ops xgbe_netdev_ops = {
> #ifdef CONFIG_NET_POLL_CONTROLLER
> .ndo_poll_controller= xgbe_poll_controller,
> #endif
> - .ndo_setup_tc = xgbe_setup_tc,
> + .ndo_setup_offload = xgbe_setup_offload,
> .ndo_fix_features =
Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
On 07/18/2018 05:11 PM, Pablo Neira Ayuso 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 > Acked-by: Jiri Pirko > Acked-by: Jakub Kicinski Acked-by: Florian Fainelli Thanks Pablo! -- Florian
Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
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 > 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 > >> 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 > >> > Acked-by: Jiri Pirko > >> > Acked-by: Jakub Kicinski > >> > >> 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=153193158512556=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.
Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
On Thu, Jul 19, 2018 at 1:52 PM, Pablo Neira Ayuso 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 >> 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 >> > Acked-by: Jiri Pirko >> > Acked-by: Jakub Kicinski >> >> 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=153193158512556=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. - Alex
Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
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 > 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 > > Acked-by: Jiri Pirko > > Acked-by: Jakub Kicinski > > 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=153193158512556=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.
Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
On Wed, Jul 18, 2018 at 5:11 PM, Pablo Neira Ayuso 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 > Acked-by: Jiri Pirko > Acked-by: Jakub Kicinski 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.
Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
On 19/07/18 01:11, Pablo Neira Ayuso 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 > Acked-by: Jiri Pirko > Acked-by: Jakub Kicinski Acked-by: Martin Habets > --- > v2: Missing function definition update in drivers/net/ethernet/sfc/falcon/tx.c > apparently I forgot to turn on that driver when doing compile-testing, > problem spotted by Martin Habets. Keeping Jakub and Jiri Acked-by tags, > as this is the only change in the v1 patch. >
[PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
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
Acked-by: Jiri Pirko
Acked-by: Jakub Kicinski
---
v2: Missing function definition update in drivers/net/ethernet/sfc/falcon/tx.c
apparently I forgot to turn on that driver when doing compile-testing,
problem spotted by Martin Habets. Keeping Jakub and Jiri Acked-by tags,
as this is the only change in the v1 patch.
drivers/net/ethernet/amd/xgbe/xgbe-drv.c| 6 +++---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 6 +++---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c| 2 +-
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 6 +++---
drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c | 6 +++---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 6 +++---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 6 +++---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 +++---
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 6 +++---
drivers/net/ethernet/intel/i40e/i40e_main.c | 6 +++---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 8
drivers/net/ethernet/intel/igb/igb_main.c | 6 +++---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +++---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 9 +
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 6 +++---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c| 6 +++---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 6 +++---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 2 +-
drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 2 +-
drivers/net/ethernet/netronome/nfp/nfp_port.c | 4 ++--
drivers/net/ethernet/netronome/nfp/nfp_port.h | 4 ++--
drivers/net/ethernet/sfc/efx.c | 2 +-
drivers/net/ethernet/sfc/efx.h | 4 ++--
drivers/net/ethernet/sfc/falcon/efx.c | 2 +-
drivers/net/ethernet/sfc/falcon/efx.h | 4 ++--
drivers/net/ethernet/sfc/falcon/tx.c| 4 ++--
drivers/net/ethernet/sfc/tx.c | 4 ++--
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
drivers/net/ethernet/ti/netcp_core.c| 6 +++---
drivers/net/netdevsim/netdev.c | 5 +++--
include/linux/netdevice.h | 18 +-
net/dsa/slave.c | 7 ---
net/sched/cls_api.c | 6 +++---
net/sched/sch_cbs.c | 8
net/sched/sch_etf.c | 8
net/sched/sch_mq.c | 8
net/sched/sch_mqprio.c | 16
net/sched/sch_prio.c| 15 ---
net/sched/sch_red.c | 15 ---
40 files changed, 131 insertions(+), 126 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index 24f1053b8785..766864a35648 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -2246,8 +2246,8 @@ static void xgbe_poll_controller(struct net_device
*netdev)
}
#endif /* End CONFIG_NET_POLL_CONTROLLER */
-static int xgbe_setup_tc(struct net_device *netdev, enum tc_setup_type type,
-void *type_data)
+static int xgbe_setup_offload(struct net_device *netdev,
+ enum tc_setup_type type, void *type_data)
{
struct xgbe_prv_data *pdata = netdev_priv(netdev);
struct tc_mqprio_qopt *mqprio = type_data;
@@ -2501,7 +2501,7 @@ static const struct net_device_ops xgbe_netdev_ops = {
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller= xgbe_poll_controller,
#endif
- .ndo_setup_tc = xgbe_setup_tc,
+ .ndo_setup_offload = xgbe_setup_offload,
.ndo_fix_features = xgbe_fix_features,
.ndo_set_features = xgbe_set_features,
.ndo_udp_tunnel_add = xgbe_udp_tunnel_add,
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 5a727d4729da..200a5938dfe5 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -4228,7 +4228,7 @@ void bnx2x_get_c2s_mapping(struct bnx2x *bp, u8 *c2s_map,
u8 *c2s_default)
* @netdev: net device
