All of lore.kernel.org
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Cc: Paolo Abeni <pabeni@redhat.com>,
	wenjia@linux.ibm.com, jaka@linux.ibm.com,
	alibuda@linux.alibaba.com, tonylu@linux.alibaba.com,
	guwen@linux.alibaba.com, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, horms@kernel.org,
	linux-rdma@vger.kernel.org, linux-s390@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Alexandra Winter <wintera@linux.ibm.com>,
	Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [PATCH net] net/smc: use the correct ndev to find pnetid by pnetid table
Date: Tue, 14 Jan 2025 13:07:47 +0100	[thread overview]
Message-ID: <20250114130747.77a56d9a.pasic@linux.ibm.com> (raw)
In-Reply-To: <b1053a92-3a3f-4042-9be9-60b94b97747d@linux.alibaba.com>

On Fri, 10 Jan 2025 13:43:44 +0800
Guangguan Wang <guangguan.wang@linux.alibaba.com> wrote:

> > I think I showed a valid and practical setup that would break with your
> > patch as is. Do you agree with that statement?  
> Did you mean
> "
> Now for something like a bond of two OSA
> interfaces, I would expect the two legs of the bond to probably have a
> "HW PNETID", but the netdev representing the bond itself won't have one
> unless the Linux admin defines a software PNETID, which is work, and
> can't have a HW PNETID because it is a software construct within Linux.
> Breaking for example an active-backup bond setup where the legs have
> HW PNETIDs and the admin did not bother to specify a PNETID for the bond
> is not acceptable.
> " ?
> If the legs have HW pnetids, add pnetid to bond netdev will fail as
> smc_pnet_add_eth will check whether the base_ndev already have HW pnetid.
> 
> If the legs without HW pnetids, and admin add pnetids to legs through smc_pnet.
> Yes, my patch will break the setup. What Paolo suggests(both checking ndev and
> base_ndev, and replace || by && )can help compatible with the setup.

I'm glad we agree on that part. Things are much more acceptable if we
are doing both base and ndev. Nevertheless I would like to understand
your problem better, and talk about it to my team. I will also ask some
questions in another email.

That said having things work differently if there is a HW PNETID on
the base, and different if there is none is IMHO wonky and again
asymmetric.

Imagine the following you have your nice little setup with a PNETID on
a non-leaf and a base_ndev that has no PNETID. Then your HW admin
configures a PNETID to your base_ndev, a different one. Suddenly
your ndev PNETID is ignored for reasons not obvious to you. Yes it is
similar to having a software PNETID on the base_ndev and getting it
overruled by a HW PNETID, but much less obvious IMHO. I also think
a software PNETID of the base should probably take precedence over over
the software pnetid of ndev.

Regards,
Halil

  reply	other threads:[~2025-01-14 12:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-27  4:04 [PATCH net] net/smc: use the correct ndev to find pnetid by pnetid table Guangguan Wang
2025-01-04 16:40 ` Jakub Kicinski
2025-01-07  2:17 ` Wen Gu
2025-01-07  8:44 ` Paolo Abeni
2025-01-07 19:32   ` Halil Pasic
2025-01-08  4:57     ` Guangguan Wang
2025-01-09  3:04       ` Halil Pasic
2025-01-10  5:43         ` Guangguan Wang
2025-01-14 12:07           ` Halil Pasic [this message]
2025-01-15 11:53             ` Guangguan Wang
2025-02-10 11:16               ` Guangguan Wang
2025-02-10 13:13                 ` Wenjia Zhang
2025-02-10 14:20                 ` Halil Pasic
2025-02-10 14:19               ` Halil Pasic
2025-02-10 13:52           ` Halil Pasic
2025-02-11  3:44             ` Guangguan Wang
2025-03-03 14:24               ` Halil Pasic
2025-03-04  2:39                 ` Guangguan Wang
2025-01-08 16:00     ` Alexandra Winter
2025-01-10  6:39       ` Guangguan Wang

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=20250114130747.77a56d9a.pasic@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=guangguan.wang@linux.alibaba.com \
    --cc=guwen@linux.alibaba.com \
    --cc=horms@kernel.org \
    --cc=jaka@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=tonylu@linux.alibaba.com \
    --cc=wenjia@linux.ibm.com \
    --cc=wintera@linux.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.