lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <CH0PR18MB4339B4BC68CABDAC3C5E4DA4CD912@CH0PR18MB4339.namprd18.prod.outlook.com>
Date: Sun, 1 Sep 2024 09:51:13 +0000
From: Geethasowjanya Akula <gakula@...vell.com>
To: Jiri Pirko <jiri@...nulli.us>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net"
	<davem@...emloft.net>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        Sunil Kovvuri Goutham
	<sgoutham@...vell.com>,
        Subbaraya Sundeep Bhatta <sbhatta@...vell.com>,
        Hariprasad Kelam <hkelam@...vell.com>
Subject: RE: [EXTERNAL] Re: [net-next PATCH v11 08/11] octeontx2-pf: Configure
 VF mtu via representor



>-----Original Message-----
>From: Jiri Pirko <jiri@...nulli.us>
>Sent: Thursday, August 22, 2024 7:54 PM
>To: Geethasowjanya Akula <gakula@...vell.com>
>Cc: netdev@...r.kernel.org; linux-kernel@...r.kernel.org; kuba@...nel.org;
>davem@...emloft.net; pabeni@...hat.com; edumazet@...gle.com; Sunil
>Kovvuri Goutham <sgoutham@...vell.com>; Subbaraya Sundeep Bhatta
><sbhatta@...vell.com>; Hariprasad Kelam <hkelam@...vell.com>
>Subject: [EXTERNAL] Re: [net-next PATCH v11 08/11] octeontx2-pf: Configure VF
>mtu via representor
>
>
>Thu, Aug 22, 2024 at 03:20:28PM CEST, gakula@...vell.com wrote:
>>Adds support to manage the mtu configuration for VF through representor.
>>On update of representor mtu a mbox notification is send to VF to
>>update its mtu.
>
>NACK
>
>Nope. If your patch does what you describe, this is certainly incorrect.
>
>VF is responsible of setting MTU itself. If you set MTU on representor netdev,
>it's related only to that, you SHOULD NOT touch VF MTU.

We implemented this feature based on the kernel representor documentation "https://docs.kernel.org/networking/representors.html"
"Setting an MTU on the representor should cause that same MTU to be reported to the representee. (On hardware that allows configuring separate and distinct MTU and MRU values, the representor MTU should correspond to the representee’s MRU and vice-versa.)"

>
>
>>
>>Signed-off-by: Sai Krishna <saikrishnag@...vell.com>
>>Signed-off-by: Geetha sowjanya <gakula@...vell.com>
>>Reviewed-by: Simon Horman <horms@...nel.org>
>>---
>> .../ethernet/marvell/octeontx2/nic/otx2_pf.c    |  5 +++++
>> .../net/ethernet/marvell/octeontx2/nic/rep.c    | 17 +++++++++++++++++
>> 2 files changed, 22 insertions(+)
>>
>>diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
>>b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
>>index cdd1f1321318..955ea941a53b 100644
>>--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
>>+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
>>@@ -854,6 +854,11 @@ static int
>>otx2_mbox_up_handler_rep_event_up_notify(struct otx2_nic *pf,  {
>> 	struct net_device *netdev = pf->netdev;
>>
>>+	if (info->event == RVU_EVENT_MTU_CHANGE) {
>>+		netdev->mtu = info->evt_data.mtu;
>>+		return 0;
>>+	}
>>+
>> 	if (info->event == RVU_EVENT_PORT_STATE) {
>> 		if (info->evt_data.port_state) {
>> 			pf->flags |= OTX2_FLAG_PORT_UP;
>>diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/rep.c
>>b/drivers/net/ethernet/marvell/octeontx2/nic/rep.c
>>index 95301faf6afe..5f767b6e79c3 100644
>>--- a/drivers/net/ethernet/marvell/octeontx2/nic/rep.c
>>+++ b/drivers/net/ethernet/marvell/octeontx2/nic/rep.c
>>@@ -79,6 +79,22 @@ int rvu_event_up_notify(struct otx2_nic *pf, struct
>rep_event *info)
>> 	return 0;
>> }
>>
>>+static int rvu_rep_change_mtu(struct net_device *dev, int new_mtu) {
>>+	struct rep_dev *rep = netdev_priv(dev);
>>+	struct otx2_nic *priv = rep->mdev;
>>+	struct rep_event evt = {0};
>>+
>>+	netdev_info(dev, "Changing MTU from %d to %d\n",
>>+		    dev->mtu, new_mtu);
>>+	dev->mtu = new_mtu;
>>+
>>+	evt.evt_data.mtu = new_mtu;
>>+	evt.pcifunc = rep->pcifunc;
>>+	rvu_rep_notify_pfvf(priv, RVU_EVENT_MTU_CHANGE, &evt);
>>+	return 0;
>>+}
>>+
>> static void rvu_rep_get_stats(struct work_struct *work)  {
>> 	struct delayed_work *del_work = to_delayed_work(work); @@ -226,6
>>+242,7 @@ static const struct net_device_ops rvu_rep_netdev_ops = {
>> 	.ndo_stop		= rvu_rep_stop,
>> 	.ndo_start_xmit		= rvu_rep_xmit,
>> 	.ndo_get_stats64	= rvu_rep_get_stats64,
>>+	.ndo_change_mtu		= rvu_rep_change_mtu,
>> };
>>
>> static int rvu_rep_napi_init(struct otx2_nic *priv,
>>--
>>2.25.1
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ