From: Denis Kenzior <denkenz@gmail.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 00/10] QRTR Multi-endpoint support
Date: Tue, 22 Oct 2024 10:46:43 -0500 [thread overview]
Message-ID: <041ff396-c5b9-40e2-8028-2b3325a3f0e3@gmail.com> (raw)
In-Reply-To: <20241022153912.hoa2wbqtkvwjzuyo@thinkpad>
Hi Mani,
On 10/22/24 10:39 AM, Manivannan Sadhasivam wrote:
> On Fri, Oct 18, 2024 at 01:18:18PM -0500, Denis Kenzior wrote:
>> The current implementation of QRTR assumes that each entity on the QRTR
>> IPC bus is uniquely identifiable by its node/port combination, with
>> node/port combinations being used to route messages between entities.
>>
>> However, this assumption of uniqueness is problematic in scenarios
>> where multiple devices with the same node/port combinations are
>> connected to the system. A practical example is a typical consumer PC
>> with multiple PCIe-based devices, such as WiFi cards or 5G modems, where
>> each device could potentially have the same node identifier set. In
>> such cases, the current QRTR protocol implementation does not provide a
>> mechanism to differentiate between these devices, making it impossible
>> to support communication with multiple identical devices.
>>
>> This patch series addresses this limitation by introducing support for
>> a concept of an 'endpoint.' Multiple devices with conflicting node/port
>> combinations can be supported by assigning a unique endpoint identifier
>> to each one. Such endpoint identifiers can then be used to distinguish
>> between devices while sending and receiving messages over QRTR sockets.
>>
>
> Thanks for your work on this! I'm yet to look into the details but wondering how
> all the patches have Reviewed-by tags provided that this series is 'RFC v1'.
> Also, it is quite surprising to see the review tag from Andy Gross who quit Qcom
> quite a while ago and I haven't seen him reviewing any Qcom patches for so long.
>
I have very limited experience in kernel development, so the first few
iterations were shared privately with a few folks to make sure I wasn't
completely off base. Andy was one of them :)
Regards,
-Denis
> - Mani
>
>> The patch series maintains backward compatibility with existing clients:
>> the endpoint concept is added using auxiliary data that can be added to
>> recvmsg and sendmsg system calls. The QRTR socket interface is extended
>> as follows:
>>
>> - Adds QRTR_ENDPOINT auxiliary data element that reports which endpoint
>> generated a particular message. This auxiliary data is only reported
>> if the socket was explicitly opted in using setsockopt, enabling the
>> QRTR_REPORT_ENDPOINT socket option. SOL_QRTR socket level was added
>> to facilitate this. This requires QRTR clients to be updated to use
>> recvmsg instead of the more typical recvfrom() or recv() use.
>>
>> - Similarly, QRTR_ENDPOINT auxiliary data element can be included in
>> sendmsg() requests. This will allow clients to route QRTR messages
>> to the desired endpoint, even in cases of node/port conflict between
>> multiple endpoints.
>>
>> - Finally, QRTR_BIND_ENDPOINT socket option is introduced. This allows
>> clients to bind to a particular endpoint (such as a 5G PCIe modem) if
>> they're only interested in receiving or sending messages to this
>> device.
>>
>> NOTE: There is 32-bit unsafe use of radix_tree_insert in this patch set.
>> This follows the existing usage inside net/qrtr/af_qrtr.c in
>> qrtr_tx_wait(), qrtr_tx_resume() and qrtr_tx_flow_failed(). This was
>> done deliberately in order to keep the changes as minimal as possible
>> until it is known whether the approach outlined is generally acceptable.
>>
>> Denis Kenzior (10):
>> net: qrtr: ns: validate msglen before ctrl_pkt use
>> net: qrtr: allocate and track endpoint ids
>> net: qrtr: support identical node ids
>> net: qrtr: Report sender endpoint in aux data
>> net: qrtr: Report endpoint for locally generated messages
>> net: qrtr: Allow sendmsg to target an endpoint
>> net: qrtr: allow socket endpoint binding
>> net: qrtr: Drop remote {NEW|DEL}_LOOKUP messages
>> net: qrtr: ns: support multiple endpoints
>> net: qrtr: mhi: Report endpoint id in sysfs
>>
>> include/linux/socket.h | 1 +
>> include/uapi/linux/qrtr.h | 7 +
>> net/qrtr/af_qrtr.c | 297 +++++++++++++++++++++++++++++++------
>> net/qrtr/mhi.c | 14 ++
>> net/qrtr/ns.c | 299 +++++++++++++++++++++++---------------
>> net/qrtr/qrtr.h | 4 +
>> 6 files changed, 459 insertions(+), 163 deletions(-)
>>
>> --
>> 2.45.2
>>
>
next prev parent reply other threads:[~2024-10-22 15:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-18 18:18 [RFC PATCH v1 00/10] QRTR Multi-endpoint support Denis Kenzior
2024-10-18 18:18 ` [RFC PATCH v1 01/10] net: qrtr: ns: validate msglen before ctrl_pkt use Denis Kenzior
2024-10-22 4:27 ` Chris Lew
2024-10-22 14:23 ` Denis Kenzior
2024-10-18 18:18 ` [RFC PATCH v1 02/10] net: qrtr: allocate and track endpoint ids Denis Kenzior
2024-10-18 18:18 ` [RFC PATCH v1 03/10] net: qrtr: support identical node ids Denis Kenzior
2024-10-19 9:18 ` Simon Horman
2024-10-22 14:24 ` Denis Kenzior
2024-10-18 18:18 ` [RFC PATCH v1 04/10] net: qrtr: Report sender endpoint in aux data Denis Kenzior
2024-10-19 0:22 ` Kuniyuki Iwashima
2024-10-22 15:07 ` Denis Kenzior
2024-10-18 18:18 ` [RFC PATCH v1 05/10] net: qrtr: Report endpoint for locally generated messages Denis Kenzior
2024-10-18 18:18 ` [RFC PATCH v1 06/10] net: qrtr: Allow sendmsg to target an endpoint Denis Kenzior
2024-10-22 23:58 ` Chris Lew
2024-10-24 17:40 ` Denis Kenzior
2024-10-18 18:18 ` [RFC PATCH v1 07/10] net: qrtr: allow socket endpoint binding Denis Kenzior
2024-10-23 5:06 ` Chris Lew
2024-10-24 17:51 ` Denis Kenzior
2024-10-18 18:18 ` [RFC PATCH v1 08/10] net: qrtr: Drop remote {NEW|DEL}_LOOKUP messages Denis Kenzior
2024-10-23 0:36 ` Chris Lew
2024-10-24 18:03 ` Denis Kenzior
2024-10-18 18:18 ` [RFC PATCH v1 09/10] net: qrtr: ns: support multiple endpoints Denis Kenzior
2024-10-18 18:18 ` [RFC PATCH v1 10/10] net: qrtr: mhi: Report endpoint id in sysfs Denis Kenzior
2024-10-23 0:25 ` Chris Lew
2024-10-24 18:06 ` Denis Kenzior
2024-10-22 15:39 ` [RFC PATCH v1 00/10] QRTR Multi-endpoint support Manivannan Sadhasivam
2024-10-22 15:46 ` Denis Kenzior [this message]
2024-10-23 5:07 ` Chris Lew
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=041ff396-c5b9-40e2-8028-2b3325a3f0e3@gmail.com \
--to=denkenz@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@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