public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Wen Gu <guwen@linux.alibaba.com>,
	Gerd Bayer <gbayer@linux.ibm.com>,
	wintera@linux.ibm.com, twinkler@linux.ibm.com, hca@linux.ibm.com,
	gor@linux.ibm.com, agordeev@linux.ibm.com, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	wenjia@linux.ibm.com, jaka@linux.ibm.com
Cc: borntraeger@linux.ibm.com, svens@linux.ibm.com,
	alibuda@linux.alibaba.com, tonylu@linux.alibaba.com,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: [RFC PATCH net-next v5 05/11] net/smc: implement DMB-related operations of loopback-ism
Date: Thu, 04 Apr 2024 17:24:08 +0200	[thread overview]
Message-ID: <60b4aec0b4bf4474d651b653c86c280dafc4518a.camel@linux.ibm.com> (raw)
In-Reply-To: <7c3733b7-a3f2-45ba-9b8d-880957ed5cdf@linux.alibaba.com>

On Thu, 2024-04-04 at 21:44 +0800, Wen Gu wrote:
> 
> On 2024/4/4 19:27, Niklas Schnelle wrote:
> > On Thu, 2024-04-04 at 18:20 +0800, Wen Gu wrote:
> > > 
> > > On 2024/4/4 01:20, Gerd Bayer wrote:
> > > > On Sun, 2024-03-24 at 21:55 +0800, Wen Gu wrote:
> > > > 
> > > > When I instrumented this to see, why I still see tons of my other
> > > > temporary instrumentation messages from the "ism" driver, I found that
> > > > in my setup loopback-ism is used rather infrequently.
> > > > 
> > > > I suspect this is due to how the SMC proposals are constructed in
> > > > net/smc/af_smc.c and net/smc/smc_pnet.c - and later evaluated in
> > > > smc_check_ism_v2_match() - where there is a first-come-first-serve
> > > > selection.
> > > > 
> > > > I wonder if one should change that to favour loopback-ism over "real"
> > > > ISM devices - and how this could be achieved elegantly.
> > > > 
> > > > Just some food for thought... Probably little you can do on x86.
> > > > 
> > > 
> > > Yes, it is about the priority of available ISM devices, and now it
> > > is decided by their order in the smcd_dev_list. The later registered
> > > ISMv2 devices(without pnetid) will be added to the beginning of the
> > > list (see smcd_register_dev()). So there is a probability that
> > > loopback-ism will not be ranked first, since it is added into list
> > > earlier during smc_init().
> > > 
> > > If we have the runtime switch of loopback-ism, we can re-active the
> > > loopback-ism, that make it be re-added into the beginning of the dev
> > > list and be chosen first. Or a new netlink command to adjust the slot
> > > order of available ISM devices in the list. As we discussed before,
> > > that could be tasks in stage 1 or stage 2.
> > > 
> > > Thanks!
> > 
> > Maybe when adding the ISM devices we could instead make sure that all
> > ISM devices are added after loopback and loopback is added in the
> > beginning. I think loopback should always be preferred and would
> > consider it a bug if it isn't faster too. Between virtio-ism and ISM it
> > may be less clear so maybe for stage 2 we would want a priority setting
> > and then insert ordered by priority. Thoughts?
> I have no objection. If we all agree, I will keep it at the beginning of the list.
> 
> Thanks!
> 
> 

I think this is a decision that needs to be made by the SMC maintainers
and Wenjia will be back next week. That said the current code basically
prioritizes ISM devices without that having been a conscious and
documented decision. Also note that due to hotplug an LPAR could be
using loopback-ism happily until suddenly an ISM device is hot plugged
and new connections suddenly switch to ISM.

  reply	other threads:[~2024-04-04 15:24 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-24 13:55 [RFC PATCH net-next v5 00/11] net/smc: SMC intra-OS shortcut with loopback-ism Wen Gu
2024-03-24 13:55 ` [RFC PATCH net-next v5 01/11] net/smc: decouple ism_client from SMC-D DMB registration Wen Gu
2024-03-24 13:55 ` [RFC PATCH net-next v5 02/11] net/smc: introduce loopback-ism for SMC intra-OS shortcut Wen Gu
2024-04-03 11:27   ` Gerd Bayer
2024-04-04  8:46     ` Wen Gu
2024-03-24 13:55 ` [RFC PATCH net-next v5 03/11] net/smc: implement ID-related operations of loopback-ism Wen Gu
2024-03-24 13:55 ` [RFC PATCH net-next v5 04/11] net/smc: implement some unsupported " Wen Gu
2024-04-03 16:25   ` Gerd Bayer
2024-04-04  9:32     ` Wen Gu
2024-04-04 11:42       ` Niklas Schnelle
2024-04-04 13:12         ` Wen Gu
2024-04-04 15:15           ` Niklas Schnelle
2024-04-09  1:44             ` Wen Gu
2024-04-11 11:12               ` Alexandra Winter
2024-04-12  2:02                 ` Wen Gu
2024-04-12 12:20                   ` Wenjia Zhang
2024-04-12 14:58                   ` Alexandra Winter
2024-03-24 13:55 ` [RFC PATCH net-next v5 05/11] net/smc: implement DMB-related " Wen Gu
2024-04-03 17:20   ` Gerd Bayer
2024-04-04 10:20     ` Wen Gu
2024-04-04 11:27       ` Niklas Schnelle
2024-04-04 13:44         ` Wen Gu
2024-04-04 15:24           ` Niklas Schnelle [this message]
2024-03-24 13:55 ` [RFC PATCH net-next v5 06/11] net/smc: ignore loopback-ism when dumping SMC-D devices Wen Gu
2024-03-24 13:55 ` [RFC PATCH net-next v5 07/11] net/smc: register loopback-ism into SMC-D device list Wen Gu
2024-03-24 13:55 ` [RFC PATCH net-next v5 08/11] net/smc: add operations to merge sndbuf with peer DMB Wen Gu
2024-03-24 13:55 ` [RFC PATCH net-next v5 09/11] net/smc: {at|de}tach sndbuf to peer DMB if supported Wen Gu
2024-03-24 13:55 ` [RFC PATCH net-next v5 10/11] net/smc: adapt cursor update when sndbuf and peer DMB are merged Wen Gu
2024-03-24 13:55 ` [RFC PATCH net-next v5 11/11] net/smc: implement DMB-merged operations of loopback-ism Wen Gu
2024-04-03  6:35 ` [RFC PATCH net-next v5 00/11] net/smc: SMC intra-OS shortcut with loopback-ism Wen Gu
2024-04-03 11:10   ` Gerd Bayer
2024-04-04 10:27     ` Wen Gu
2024-04-11  7:45     ` Wen Gu
2024-04-11  9:32       ` Wenjia Zhang
2024-04-11  9:56         ` Wen Gu

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=60b4aec0b4bf4474d651b653c86c280dafc4518a.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gbayer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=guwen@linux.alibaba.com \
    --cc=hca@linux.ibm.com \
    --cc=jaka@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=svens@linux.ibm.com \
    --cc=tonylu@linux.alibaba.com \
    --cc=twinkler@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox