From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D83EC43140 for ; Thu, 5 Sep 2019 16:02:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C43A920870 for ; Thu, 5 Sep 2019 16:02:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=st.com header.i=@st.com header.b="tIYrAWAR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389422AbfIEQCN (ORCPT ); Thu, 5 Sep 2019 12:02:13 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:51554 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730937AbfIEQCM (ORCPT ); Thu, 5 Sep 2019 12:02:12 -0400 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx08-00178001.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x85G1k8B024599; Thu, 5 Sep 2019 18:02:05 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=STMicroelectronics; bh=9aNLD8I30iSCXYQuoK3fnEQebuHYYFccizzyDOOMuIA=; b=tIYrAWARMx++UdA4uU7k6oR72UH7TwVXEoFVmS4UiBNxJEO+PInhoDnJaWSka5FNyje+ lYEgpKfMCcMNpa4WK5KbhQyHtAm2nroBwpHXNci89kpwnEoKo5VngQT7XklD+rggnmU4 O/BWljUvIok0S0s5kjjhNoAltc0ejt3Z/vZ2+ihIrZFCHcWG4CMgBxHDSIX5r7RKzNsz 2UlqId7PszmPkwwqgCB5tVBxZJxji+Y2bvn1RLiO8C8gySQBh3LfO2I/1MQS/wWP32xq 6zyhtYPJcGs5Gak5CN9a5DlBAEne5Vgur7nEgERl2kyVbOgI7QbMMcUYPeKdl2UMDuXh /g== Received: from beta.dmz-ap.st.com (beta.dmz-ap.st.com [138.198.100.35]) by mx08-00178001.pphosted.com with ESMTP id 2uqfsj90jk-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 05 Sep 2019 18:02:05 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-ap.st.com (STMicroelectronics) with ESMTP id D40A64E; Thu, 5 Sep 2019 16:02:01 +0000 (GMT) Received: from Webmail-eu.st.com (sfhdag3node1.st.com [10.75.127.7]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 382102FF5EA; Thu, 5 Sep 2019 18:02:01 +0200 (CEST) Received: from [10.48.0.131] (10.75.127.48) by SFHDAG3NODE1.st.com (10.75.127.7) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 5 Sep 2019 18:02:00 +0200 Subject: Re: [PATCH 1/3] rpmsg: core: add API to get message length To: Jeffrey Hugo CC: Ohad Ben-Cohen , Bjorn Andersson , lkml , , MSM , Suman Anna , Fabien DESSENNE , References: <1567693630-27544-1-git-send-email-arnaud.pouliquen@st.com> <1567693630-27544-2-git-send-email-arnaud.pouliquen@st.com> From: Arnaud Pouliquen Message-ID: <8e87ccff-1bdb-255c-0be4-db34869f0d13@st.com> Date: Thu, 5 Sep 2019 18:02:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.48] X-ClientProxiedBy: SFHDAG6NODE3.st.com (10.75.127.18) To SFHDAG3NODE1.st.com (10.75.127.7) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-05_05:2019-09-04,2019-09-05 signatures=0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jeffrey, On 9/5/19 4:42 PM, Jeffrey Hugo wrote: > On Thu, Sep 5, 2019 at 8:35 AM Arnaud Pouliquen wrote: >> >> Return the rpmsg buffer size for sending message, so rpmsg users >> can split a long message in several sub rpmsg buffers. >> >> Signed-off-by: Arnaud Pouliquen >> --- >> drivers/rpmsg/rpmsg_core.c | 21 +++++++++++++++++++++ >> drivers/rpmsg/rpmsg_internal.h | 2 ++ >> drivers/rpmsg/virtio_rpmsg_bus.c | 10 ++++++++++ >> include/linux/rpmsg.h | 10 ++++++++++ >> 4 files changed, 43 insertions(+) >> >> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c >> index e330ec4dfc33..a6ef54c4779a 100644 >> --- a/drivers/rpmsg/rpmsg_core.c >> +++ b/drivers/rpmsg/rpmsg_core.c >> @@ -283,6 +283,27 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst, >> } >> EXPORT_SYMBOL(rpmsg_trysend_offchannel); >> >> +/** >> + * rpmsg_get_mtu() - get maximum transmission buffer size for sending message. >> + * @ept: the rpmsg endpoint >> + * >> + * This function returns maximum buffer size available for a single message. >> + * >> + * Return: the maximum transmission size on success and an appropriate error >> + * value on failure. >> + */ > > What is the intent of this? > > The term "mtu" is "maximum transfer unit" - ie the largest payload of > data that could possibly be sent, however at any one point in time, > that might not be able to be accommodated. I was not aware that the MTU has to be static in time. And I'm not enough expert to be able challenge this. The use of the MTU initially came from a Bjorn request and IMHO makes sense in RPMSG protocol as other protocols. The aim here is not to guaranty the available size but to provide to rpmsg client a packet size information that is not available today at rpmsg client level. For instance for the virtio rpmsg bus we provide the size of a vring buffer, not the total size available in the vring. > > I don't think this is implemented correctly. In GLINK and SMD, you've > not implemented MTU, you've implemented "how much can I send at this > point in time". To me, this is not mtu. If MTU has to be static i agree with you. > > In the case of SMD, you could get the fifo size and return that as the > mtu, but since you seem to be wanting to use this from the TTY layer > to determine how much can be sent at a particular point in time, I > don't think you actually want mtu. Please forget the TTY for the moment, The mtu is used to help the tty framework to split the buffer to write. The size is then adjusted on write. For SMD i can provide the fifo_size,or a division of this size to "limit" congestion. would this make sense for you? > > For GLINK, I don't actually think you can get a mtu based on the > design, but I'm trying to remember from 5-6 years ago when we designed > it. It would be possible that a larger intent would be made available > later. Is it possible to have the largest intent? or it's not deterministic. > > I think you need to first determine if you are actually looking for > mtu, or "how much data can I send right now", because right now, it > isn't clear. > In my view it is the MTU. "how much data can I send right now" is an information that is very volatile as buffers can be shared between several clients, therefore unusable. An alternative would be to make this ops optional, but that would mean that some generic clients would not be compatible with SMD and/or Glink drivers. Thanks, Arnaud