Message-ID: <20241225125649.2595970-1-gur.stavi@huawei.com>
Date: Wed, 25 Dec 2024 14:56:49 +0200
From: Gur Stavi <gur.stavi@...wei.com>
To: <kuba@...nel.org>
CC: <andrew+netdev@...n.ch>, <cai.huoqing@...ux.dev>, <corbet@....net>,
	<davem@...emloft.net>, <edumazet@...gle.com>, <gongfan1@...wei.com>,
	<guoxin09@...wei.com>, <gur.stavi@...wei.com>, <helgaas@...nel.org>,
	<horms@...nel.org>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <meny.yossefi@...wei.com>,
	<netdev@...r.kernel.org>, <pabeni@...hat.com>, <shenchenyang1@...ilicon.com>,
	<shijing34@...wei.com>, <wulike1@...wei.com>, <zhoushuai28@...wei.com>
Subject: Re: [PATCH net-next v01 1/1] hinic3: module initialization and tx/rx logic

> > > On Thu, 19 Dec 2024 11:21:55 +0200 Gur Stavi wrote:
> > > > +config HINIC3
> > > > +	tristate "Huawei Intelligent Network Interface Card 3rd"
> > > > +	# Fields of HW and management structures are little endian and will not
> > > > +	# be explicitly converted
> > >
> > > This is a PCIe device, users may plug it into any platform.
> > > Please annotate the endian of the data structures and use appropriate
> > > conversion helpers.
> >
> > This is basically saying that all drivers MUST support all architectures
> > which is not a currently documented requirement.
> > As I said before, both Amazon and Microsoft have this dependency.
> > They currently do not sell their HW so users cannot choose where to plug
> > it, but they could start selling it whenever they want and the driver will
> > remain the same.
> > The primary goal of this driver is for VMs in Huawei cloud, just like
> > Amazon and Microsoft. Whether users can actually buy it in the future is
> > unknown.
> >
> > for the record, we did start at some point to change all integer members
> > in management structures to __leXX and use cpu_to_le and le_to_cpu.
> > There are hundreds of these and it made the code completely unreadable.
> >
> > And since we do not plan to test the driver on POWER or ARM big endian I
> > really don't see the point.
>
> I understand. But I'm concerned about the self-assured tone of the
> "it's not supported" message, that's very corporate verbiage. Annotating
> endian is standard practice of writing upstream drivers. It makes me
> doubt if you have any developers with upstream experience on your team
> if you don't know that. That and the fact that Huawei usually tops
> the list of net-negative review contributors in netdev.

The most popular combination in the last 3 decades was little endian
CPUs with big endian device interfaces. Endianity conversion was a
necessity and therefore endian annotation became standard practice.
But it was never symmetric, conversion to/from BE was more common than
conversion to/from LE.

As the pendulum moved from horizontal market to vertical market and major
companies started to develop both hw and sw, the hw engineers transformed
proprietary parts of the interface to little endian to save extra work in
the sw. AWS did it. Azure did it. Huawei did it. These vertical companies
do not care about endianity of CPUs they do not use.
This is not "corporate verbiage" this is a real market shift.

The necessity for endian conversion is gone (or just halved). Will the
standard practice remain? There is not a single __le annotation in Amazon
and Microsoft code. Not in Mellanox code either. Maybe their hw is fully
BE (have to wonder about their DPUs). Amazingly, Intel that only creates
little endian CPUs has lots of __le annotations. But they are the flag
barer of horizontal market.

Interesting how both Amazon and Microsoft started with:
depends on X86
Thus evaded demand for adding __le annotations to the code.
Later, both sneaked in quiet small patches with replacement to:
depends on !CPU_BIG_ENDIAN
Maybe that is the true meaning of "upstream experience".

Powered by blists - more mailing lists