Received-SPF: pass (google.com: domain of linux-kernel+bounces-111955-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
To: Andrew Lunn <andrew@lunn.ch>
CC: "Parthiban.Veerasooran@microchip.com"
	<Parthiban.Veerasooran@microchip.com>,
        "davem@davemloft.net"
	<davem@davemloft.net>,
        "edumazet@google.com" <edumazet@google.com>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "pabeni@redhat.com" <pabeni@redhat.com>,
        "horms@kernel.org" <horms@kernel.org>,
        "saeedm@nvidia.com"
	<saeedm@nvidia.com>,
        "anthony.l.nguyen@intel.com"
	<anthony.l.nguyen@intel.com>,
        "netdev@vger.kernel.org"
	<netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "robh+dt@kernel.org"
	<robh+dt@kernel.org>,
        "krzysztof.kozlowski+dt@linaro.org"
	<krzysztof.kozlowski+dt@linaro.org>,
        "conor+dt@kernel.org"
	<conor+dt@kernel.org>,
        "devicetree@vger.kernel.org"
	<devicetree@vger.kernel.org>,
        "Horatiu.Vultur@microchip.com"
	<Horatiu.Vultur@microchip.com>,
        "ruanjinjie@huawei.com"
	<ruanjinjie@huawei.com>,
        "Steen.Hegelund@microchip.com"
	<Steen.Hegelund@microchip.com>,
        "vladimir.oltean@nxp.com"
	<vladimir.oltean@nxp.com>,
        "UNGLinuxDriver@microchip.com"
	<UNGLinuxDriver@microchip.com>,
        "Thorsten.Kummermehr@microchip.com"
	<Thorsten.Kummermehr@microchip.com>,
        Piergiorgio Beruto
	<Pier.Beruto@onsemi.com>,
        "Nicolas.Ferre@microchip.com"
	<Nicolas.Ferre@microchip.com>,
        "benjamin.bigler@bernformulastudent.ch"
	<benjamin.bigler@bernformulastudent.ch>
Subject: RE: [PATCH net-next v3 08/12] net: ethernet: oa_tc6: implement
 transmit path to transfer tx ethernet frames
Thread-Topic: [PATCH net-next v3 08/12] net: ethernet: oa_tc6: implement
 transmit path to transfer tx ethernet frames
Thread-Index: 
 AQHab6OUNkEIC/2nOEKl31mx3SAVeLEshPoAgBKU6ACAAAbvgIABZr4AgAIaygCAAA4oAIABfYQw
Date: Fri, 22 Mar 2024 18:31:05 +0000
Message-ID: 
 <BYAPR02MB5958165A052E6EA11C353E6883312@BYAPR02MB5958.namprd02.prod.outlook.com>
References: <20240306085017.21731-1-Parthiban.Veerasooran@microchip.com>
 <20240306085017.21731-9-Parthiban.Veerasooran@microchip.com>
 <208fb61b-4740-46bf-8c70-29ab59cbb965@lunn.ch>
 <f9d8a18c-b1fe-450c-a5ca-d91f96793a04@microchip.com>
 <96dd422f-0bf9-411d-8cc2-5755c1e60e27@lunn.ch>
 <53b090b1-d7bb-4a81-9f0b-9979db8dec59@microchip.com>
 <BYAPR02MB5958A04EF61FF6B7512CE7EE83322@BYAPR02MB5958.namprd02.prod.outlook.com>
 <f9ded7f6-7f7d-4564-8b06-e73e603ef927@lunn.ch>
In-Reply-To: <f9ded7f6-7f7d-4564-8b06-e73e603ef927@lunn.ch>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?3pCtqOwTFJLM91rqyMTyXVnxTLDQ+W2hjA3yoWAlPIBIiQJ2cw4ME/gMeCsx?=
 =?us-ascii?Q?d84LsuaCeKs6MPoCii+s4tUs1fOSGjrdxOh83mYUuGE8to/mLRT8Bmkt/G5W?=
 =?us-ascii?Q?WAsVKzrDAzYYatGzbR6TLYiD+R+L2dDqilW7+Zda6pTrGBdyJk3ID+KTxE5t?=
 =?us-ascii?Q?oN/Kts3s/VUPg3JojPEV8ufPU5JB8Qhn7d8Lv2Pwz6jCM4YlRYyv+0Q6xuib?=
 =?us-ascii?Q?+lw6j1L8csLPsQWOwgsPw47AN6r2NNEgapTU2kAHFd47Mg/r91BNXHrUBtqE?=
 =?us-ascii?Q?weSAQrvBHVomrz9VGSzEEpYSUogCWLhP1S1OWMwV8fRL6VMJrencQiqAO8xP?=
 =?us-ascii?Q?U3wpf4cpsicK/nhGHWlyfB+M5AtMh9FGpGjqhhaKZqbuCTbAOi6HncdVH1mP?=
 =?us-ascii?Q?S8CYwd5bB5atN026AjXSlNKmHutHDX3wx7yfl3vp4t4GhGrLYiFJkYP/MNoa?=
 =?us-ascii?Q?VDgLn7nIS9QpMziv2K6ACeEeHp301zaTYT3d9mxADyTBw/l0oDbEoYG46Plv?=
 =?us-ascii?Q?TTWbtlzp5X05OqHUKBNVry6A51dL6/sYd4gMOTMR9+ZtH2kCKhreYVgFSUNO?=
 =?us-ascii?Q?BzlVr0D0iUrgU58//Qh15RKks94tA/wgRgGsD6bYDNQA5aKuKSUlCIvJLogi?=
 =?us-ascii?Q?3sTckQHydhYRPwn374Ly3hDcBiQzVYqwgae6DINF4/Ig5GTBjMe+NF15JwwM?=
 =?us-ascii?Q?OL+kGDwa5PXJKTdYwdhOJZvy337Vd24sb3/p5xI0iRp6fz6ru02qIQ0pkpCD?=
 =?us-ascii?Q?Cl7UP5fdjGIHvGROTHDgzAQLOeslK2WlEjXNoKsj9A/EyJiqCt728lb+6OGD?=
 =?us-ascii?Q?NXnuBeuCskqCEgtxBuIA1SgcUk02wewjc2SWKx4yFUK02QbEFovCqvlNbj99?=
 =?us-ascii?Q?eKOkc2S3mVMq0Sl907eS6qNDszx2b1idaerGniNjNqJBZcdX9u88XZ5rvyyr?=
 =?us-ascii?Q?EsY8BJix/8paamX1kB+gVoRgevxVjGLv9QjqvbYSG3mWgWHrldTQe8ROBCWu?=
 =?us-ascii?Q?sML/IihrptsgSABaF1Te5oQe70mEHBBvzeIdZY6Dhd7vNiyJ2Of5HIk9N6K6?=
 =?us-ascii?Q?AFa8rEb26xb2eLvHeDwOhKlMswLHqulF3EqEaW9qpg5XLL0NA2j3o4D56N4M?=
 =?us-ascii?Q?ZLkhx97TJzFoElBKEyThKHjw7EqBUj1GRWHDy882g1OhF6dFR4WqOZxP3cYU?=
 =?us-ascii?Q?J81uSmk+a0slJzH77Ik+yTVbV3smz0UnESssUPvOdKm5ucgNWAdxiqFcrFCN?=
 =?us-ascii?Q?JohgR5/gz+UqzRVqX/9DLKZwh1sQRBdz6h2ntiHZSGy7F9lb4vaghH+lHxcM?=
 =?us-ascii?Q?wXZWKIo0f8V6etAwNkTkTawdzMRoY5rKOH0l8irFWIsJ87sxVJvsLW1wVW+C?=
 =?us-ascii?Q?QC3fUF5cP3a6LxITVkeMU1NvlmH2pyBtaS+kfcWGBOTfb2pZOwvhVrXGTxBA?=
 =?us-ascii?Q?ll3+iYef0dDmldmp26lYtXOVBvulvyWoZAYK1tzy3QEEzBxGeRsp7n7pauWL?=
 =?us-ascii?Q?/OmaxjrZWdrM2Q0xiXlem+kcnAYZeXs21ABQPowATR7FO2HuFQOnVEqxm+vo?=
 =?us-ascii?Q?/oaoFP/pfeyyHqUJX63vWeasZuNr8tQNXr9m/eoodg9jBT8VZCWR3UIfmxhC?=
 =?us-ascii?Q?hA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: onsemi.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR02MB5958.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0fb4fd04-4f2e-427c-13fb-08dc4a9e3c42
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2024 18:31:05.5683
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 04e1674b-7af5-4d13-a082-64fc6e42384c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: JmX9cEBf0rTXvlgirdMCKk1hCQj9ahjqdnOt3w9GmK8zMoJl93r2ddP2k+e6K74DkJB8dgHWtIUSQfedTR9nAQBaSS3/gz1PiG3eahXDl1M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR02MB9887
X-Proofpoint-GUID: Ct7RQOx_ZdQybCC5oVylzW6WTF4NGalK
X-Proofpoint-ORIG-GUID: Ct7RQOx_ZdQybCC5oVylzW6WTF4NGalK
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-22_10,2024-03-21_02,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 impostorscore=0
 suspectscore=0 bulkscore=0 spamscore=0 adultscore=0 mlxscore=0
 priorityscore=1501 mlxlogscore=999 phishscore=0 lowpriorityscore=0
 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2403210001 definitions=main-2403220133


> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Thursday, March 21, 2024 12:42 PM
> To: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> Cc: Parthiban.Veerasooran@microchip.com; davem@davemloft.net;
> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com;
> horms@kernel.org; saeedm@nvidia.com; anthony.l.nguyen@intel.com;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; corbet@lwn.net;
> linux-doc@vger.kernel.org; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org;
> devicetree@vger.kernel.org; Horatiu.Vultur@microchip.com;
> ruanjinjie@huawei.com; Steen.Hegelund@microchip.com;
> vladimir.oltean@nxp.com; UNGLinuxDriver@microchip.com;
> Thorsten.Kummermehr@microchip.com; Piergiorgio Beruto
> <Pier.Beruto@onsemi.com>; Nicolas.Ferre@microchip.com;
> benjamin.bigler@bernformulastudent.ch
> Subject: Re: [PATCH net-next v3 08/12] net: ethernet: oa_tc6:
> implement transmit path to transfer tx ethernet frames
>=20
> [External Email]: This email arrived from an external source - Please
> exercise caution when opening any attachments or clicking on links.
>=20
> > > > This second part is clearly an optimisation. If you have lots of
> > > > full MTU packets, 1514 bytes, they take around 24 chunks. Having
> > > > the last chunk only 1/2 full does not waste too much bandwidth.
> > > > But if you are carrying lots of small packets, say voice, 130
> > > > bytes, the wasted bandwidth starts to add up. But is there a use
> > > > case for 10Mbps of small packets? I doubt it.
> > > Yes, for sure there is a possibility to get into this scenario and
> > > the protocol also supports that. But as proposed by you below, let's
> > > implement it as part of optimization later.
> > > >
> > > > So if you don't have the ability to combine two packets into one
> > > > chunk, i would do that later. Lets get the basics merged first, it
> > > > can be optimised later.
> > > Yes, I agree with this proposal to get the basic version merged first=
.
> >
> > While latency is important, so is using the available bandwidth
> > efficiently. Here is a suggestion.  We know that the tx credit
> > available basically tells us, how many chunks could be transmitted
> without overflow. Instead of stopping the netif queue based on number
> of skbs queued, why not stop the queue based on number of bytes
> accumulated? Basically, at any given point of time, we enqueue the
> tx_skb_q until we are have enough bytes to cross the threshold of (tc6-
> >tc_credit * OA_TC6_CHUNK_PAYLOAD_SIZE).
> > This way, during the next transmit, we could utilize the whole availabl=
e
> credits. Bandwidth utilization between bigger frames and smaller
> frames would be not be vastly different.
>=20
> Please configure your email client to wrap emails at around 70
> characters.
>=20
> tc_credit is 5 bits. So it is a maximum of 32.
>=20
> A 1514 frame takes around 24 chunks. So you only need two full size
> frames to consume all your possible credit.
>=20
> If you happen to have smaller voice packets, say 130 bytes, you need
> three chunks to send it. So you might want to have 10 such packets on
> hand in order to make use of all your credit. But if you have 10 voice
> packets to send in a burst, your voice quality is going to be bad, they
> should be 10ms to 20ms apart, not in a burst...
>=20
> I don't like the original idea of having lots of packets in a transmit qu=
eue.
> But having 1/2 dozen should not be an issue.
>=20
> In general, we prefer things to be simple. We can then optimise later,
> and use benchmarks to show the optimisations really do bring a benefit
> to justify the added complexity.

True. I should get some performance numbers to see where we are
with the current code. That would be time to look at the improvement.=20

>=20
>    Andrew