From: Jakub Kicinski <kuba@kernel.org>
To: Shinas Rasheed <srasheed@marvell.com>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<hgani@marvell.com>, <sedara@marvell.com>, <vimleshk@marvell.com>,
<thaller@redhat.com>, <wizhao@redhat.com>, <kheib@redhat.com>,
<egallen@redhat.com>, <konguyen@redhat.com>, <horms@kernel.org>,
<einstein.xue@synaxg.com>,
Veerasenareddy Burru <vburru@marvell.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH net-next v2] octeon_ep: add ndo ops for VFs in PF driver
Date: Thu, 14 Nov 2024 19:16:48 -0800 [thread overview]
Message-ID: <20241114191648.34410e79@kernel.org> (raw)
In-Reply-To: <20241112185432.1152541-1-srasheed@marvell.com>
On Tue, 12 Nov 2024 10:54:31 -0800 Shinas Rasheed wrote:
> These APIs are needed to support applications that use netlink to get VF
> information from a PF driver.
>
> Signed-off-by: Shinas Rasheed <srasheed@marvell.com>
> +static int octep_get_vf_config(struct net_device *dev, int vf, struct ifla_vf_info *ivi)
Please don't go over 80 chars for no good reason.
use checkpatch with --strict --max-line-length=80
> +{
> + struct octep_device *oct = netdev_priv(dev);
> +
> + ivi->vf = vf;
> + ether_addr_copy(ivi->mac, oct->vf_info[vf].mac_addr);
> + ivi->vlan = 0;
> + ivi->qos = 0;
no need to clear these fields
> + ivi->spoofchk = 0;
> + ivi->linkstate = IFLA_VF_LINK_STATE_ENABLE;
> + ivi->trusted = true;
so you set spoofchk to 0 and trusted to true, indicating no
enforcement [1]
> + ivi->max_tx_rate = 10000;
> + ivi->min_tx_rate = 0;
Why are you setting max rate to a fixed value?
> +
> + return 0;
> +}
> +
> +static int octep_set_vf_mac(struct net_device *dev, int vf, u8 *mac)
> +{
> + struct octep_device *oct = netdev_priv(dev);
> + int err;
> +
> + if (!is_valid_ether_addr(mac)) {
> + dev_err(&oct->pdev->dev, "Invalid MAC Address %pM\n", mac);
> + return -EADDRNOTAVAIL;
> + }
> +
> + dev_dbg(&oct->pdev->dev, "set vf-%d mac to %pM\n", vf, mac);
> + ether_addr_copy(oct->vf_info[vf].mac_addr, mac);
> + oct->vf_info[vf].flags |= OCTEON_PFVF_FLAG_MAC_SET_BY_PF;
double space
> +
> + err = octep_ctrl_net_set_mac_addr(oct, vf, mac, true);
> + if (err)
> + dev_err(&oct->pdev->dev, "Set VF%d MAC address failed via host control Mbox\n", vf);
> +
> + return err;
> +}
> +
> static const struct net_device_ops octep_netdev_ops = {
> .ndo_open = octep_open,
> .ndo_stop = octep_stop,
> @@ -1146,6 +1184,9 @@ static const struct net_device_ops octep_netdev_ops = {
> .ndo_set_mac_address = octep_set_mac,
> .ndo_change_mtu = octep_change_mtu,
> .ndo_set_features = octep_set_features,
> + /* for VFs */
what does this comment achieve?
> + .ndo_get_vf_config = octep_get_vf_config,
> + .ndo_set_vf_mac = octep_set_vf_mac
> };
>
> /**
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_main.h b/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
> index fee59e0e0138..3b56916af468 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
> @@ -220,6 +220,7 @@ struct octep_iface_link_info {
> /* The Octeon VF device specific info data structure.*/
> struct octep_pfvf_info {
> u8 mac_addr[ETH_ALEN];
> + u32 flags;
the flags are u32 [2]
> u32 mbox_version;
> };
>
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c
> index e6eb98d70f3c..26db2d34d1c0 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c
> @@ -156,12 +156,23 @@ static void octep_pfvf_set_mac_addr(struct octep_device *oct, u32 vf_id,
> {
> int err;
>
> + if (oct->vf_info[vf_id].flags & OCTEON_PFVF_FLAG_MAC_SET_BY_PF) {
> + dev_err(&oct->pdev->dev,
> + "VF%d attempted to override administrative set MAC address\n",
> + vf_id);
> + rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_NACK;
> + return;
> + }
[1] and yet you reject VF side changes. So is there enforcement or not?
:S
> err = octep_ctrl_net_set_mac_addr(oct, vf_id, cmd.s_set_mac.mac_addr, true);
> if (err) {
> rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_NACK;
> - dev_err(&oct->pdev->dev, "Set VF MAC address failed via host control Mbox\n");
> + dev_err(&oct->pdev->dev, "Set VF%d MAC address failed via host control Mbox\n",
> + vf_id);
> return;
> }
> +
> + ether_addr_copy(oct->vf_info[vf_id].mac_addr, cmd.s_set_mac.mac_addr);
> rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
> }
>
> @@ -171,10 +182,17 @@ static void octep_pfvf_get_mac_addr(struct octep_device *oct, u32 vf_id,
> {
> int err;
>
> + if (oct->vf_info[vf_id].flags & OCTEON_PFVF_FLAG_MAC_SET_BY_PF) {
> + dev_dbg(&oct->pdev->dev, "VF%d MAC address set by PF\n", vf_id);
> + ether_addr_copy(rsp->s_set_mac.mac_addr, oct->vf_info[vf_id].mac_addr);
> + rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
> + return;
> + }
> err = octep_ctrl_net_get_mac_addr(oct, vf_id, rsp->s_set_mac.mac_addr);
> if (err) {
> rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_NACK;
> - dev_err(&oct->pdev->dev, "Get VF MAC address failed via host control Mbox\n");
> + dev_err(&oct->pdev->dev, "Get VF%d MAC address failed via host control Mbox\n",
> + vf_id);
> return;
> }
> rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.h b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.h
> index 0dc6eead292a..339977c7131a 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.h
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.h
> @@ -23,6 +23,9 @@ enum octep_pfvf_mbox_version {
>
> #define OCTEP_PFVF_MBOX_VERSION_CURRENT OCTEP_PFVF_MBOX_VERSION_V2
>
> +/* VF flags */
> +#define OCTEON_PFVF_FLAG_MAC_SET_BY_PF BIT_ULL(0) /* PF has set VF MAC address */
[2] but the bit definition uses ULL ?
> enum octep_pfvf_mbox_opcode {
> OCTEP_PFVF_MBOX_CMD_VERSION,
> OCTEP_PFVF_MBOX_CMD_SET_MTU,
--
pw-bot: cr
next prev parent reply other threads:[~2024-11-15 3:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 18:54 [PATCH net-next v2] octeon_ep: add ndo ops for VFs in PF driver Shinas Rasheed
2024-11-13 3:50 ` Kalesh Anakkur Purayil
2024-11-13 13:46 ` Simon Horman
2024-11-15 3:16 ` Jakub Kicinski [this message]
2024-11-16 17:21 ` [EXTERNAL] " Shinas Rasheed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241114191648.34410e79@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=egallen@redhat.com \
--cc=einstein.xue@synaxg.com \
--cc=hgani@marvell.com \
--cc=horms@kernel.org \
--cc=kheib@redhat.com \
--cc=konguyen@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sedara@marvell.com \
--cc=srasheed@marvell.com \
--cc=thaller@redhat.com \
--cc=vburru@marvell.com \
--cc=vimleshk@marvell.com \
--cc=wizhao@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).