From: Jeremy Kerr <jk@codeconstruct.com.au>
To: Jakub Kicinski <kuba@kernel.org>,
Khang Nguyen <khangng@os.amperecomputing.com>
Cc: Matt Johnston <matt@codeconstruct.com.au>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
ampere-linux-kernel@lists.amperecomputing.com,
Phong Vo <phong@os.amperecomputing.com>,
Thang Nguyen <thang@os.amperecomputing.com>,
Khanh Pham <khpham@amperecomputing.com>,
Phong Vo <pvo@amperecomputing.com>,
Quan Nguyen <quan@os.amperecomputing.com>,
Chanh Nguyen <chanh@os.amperecomputing.com>,
Thu Nguyen <thu@os.amperecomputing.com>,
Hieu Le <hieul@amperecomputing.com>,
openbmc@lists.ozlabs.org, patches@amperecomputing.com
Subject: Re: [PATCH net-next] net: mctp: Expose transport binding identifier via IFLA attribute
Date: Fri, 08 Nov 2024 16:10:49 +0800 [thread overview]
Message-ID: <84fa07f08bce8af2018e4f81949d227c9b97fe0c.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20241107204157.683bca11@kernel.org>
Hi Jakub,
> > However, we currently have no means to get this information from
> > MCTP links.
>
> I'm not opposed to the netlink attribute, but to be clear this info
> is indirectly available in sysfs, right? We link the netdev to
> the parent device so the type of /sys/class/net/$your_ifc/device
> should reveal what the transport is?
It's likely derivable from the parent device, but requires some
heuristics in userspace to map this to a transport type.
Having a well-defined place to provide the DMTF-specified transport
identifier makes this a little more straightforward to determine which
spec we're dealing with, for any transport-specific behaviour. For
example, some bus types require endpoints to announce their presence,
others do not.
Cheers,
Jeremy
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Kerr <jk@codeconstruct.com.au>
To: Jakub Kicinski <kuba@kernel.org>,
Khang Nguyen <khangng@os.amperecomputing.com>
Cc: patches@amperecomputing.com,
Thu Nguyen <thu@os.amperecomputing.com>,
Khanh Pham <khpham@amperecomputing.com>,
netdev@vger.kernel.org, openbmc@lists.ozlabs.org,
Thang Nguyen <thang@os.amperecomputing.com>,
linux-kernel@vger.kernel.org,
ampere-linux-kernel@lists.amperecomputing.com,
Phong Vo <phong@os.amperecomputing.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Eric Dumazet <edumazet@google.com>,
Hieu Le <hieul@amperecomputing.com>,
Quan Nguyen <quan@os.amperecomputing.com>,
Simon Horman <horms@kernel.org>,
Phong Vo <pvo@amperecomputing.com>,
Matt Johnston <matt@codeconstruct.com.au>,
Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Chanh Nguyen <chanh@os.amperecomputing.com>
Subject: Re: [PATCH net-next] net: mctp: Expose transport binding identifier via IFLA attribute
Date: Fri, 08 Nov 2024 16:10:49 +0800 [thread overview]
Message-ID: <84fa07f08bce8af2018e4f81949d227c9b97fe0c.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20241107204157.683bca11@kernel.org>
Hi Jakub,
> > However, we currently have no means to get this information from
> > MCTP links.
>
> I'm not opposed to the netlink attribute, but to be clear this info
> is indirectly available in sysfs, right? We link the netdev to
> the parent device so the type of /sys/class/net/$your_ifc/device
> should reveal what the transport is?
It's likely derivable from the parent device, but requires some
heuristics in userspace to map this to a transport type.
Having a well-defined place to provide the DMTF-specified transport
identifier makes this a little more straightforward to determine which
spec we're dealing with, for any transport-specific behaviour. For
example, some bus types require endpoints to announce their presence,
others do not.
Cheers,
Jeremy
next prev parent reply other threads:[~2024-11-08 8:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-05 7:19 [PATCH net-next] net: mctp: Expose transport binding identifier via IFLA attribute Khang Nguyen
2024-11-05 7:19 ` Khang Nguyen
2024-11-07 3:05 ` Matt Johnston
2024-11-07 3:05 ` Matt Johnston
2024-11-08 4:41 ` Jakub Kicinski
2024-11-08 4:41 ` Jakub Kicinski
2024-11-08 5:47 ` Khang D Nguyen
2024-11-08 5:47 ` Khang D Nguyen
2024-11-08 8:10 ` Jeremy Kerr [this message]
2024-11-08 8:10 ` Jeremy Kerr
2024-11-09 17:50 ` patchwork-bot+netdevbpf
2024-11-09 17:50 ` patchwork-bot+netdevbpf
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=84fa07f08bce8af2018e4f81949d227c9b97fe0c.camel@codeconstruct.com.au \
--to=jk@codeconstruct.com.au \
--cc=ampere-linux-kernel@lists.amperecomputing.com \
--cc=andrew+netdev@lunn.ch \
--cc=chanh@os.amperecomputing.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hieul@amperecomputing.com \
--cc=horms@kernel.org \
--cc=khangng@os.amperecomputing.com \
--cc=khpham@amperecomputing.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeconstruct.com.au \
--cc=netdev@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=pabeni@redhat.com \
--cc=patches@amperecomputing.com \
--cc=phong@os.amperecomputing.com \
--cc=pvo@amperecomputing.com \
--cc=quan@os.amperecomputing.com \
--cc=thang@os.amperecomputing.com \
--cc=thu@os.amperecomputing.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.