linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Gur Stavi <gur.stavi@huawei.com>
Cc: <andrew+netdev@lunn.ch>, <cai.huoqing@linux.dev>,
	<corbet@lwn.net>, <davem@davemloft.net>, <edumazet@google.com>,
	<gongfan1@huawei.com>, <guoxin09@huawei.com>,
	<helgaas@kernel.org>, <horms@kernel.org>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<meny.yossefi@huawei.com>, <netdev@vger.kernel.org>,
	<pabeni@redhat.com>, <shenchenyang1@hisilicon.com>,
	<shijing34@huawei.com>, <wulike1@huawei.com>,
	<zhoushuai28@huawei.com>
Subject: Re: [PATCH net-next v01 1/1] hinic3: module initialization and tx/rx logic
Date: Mon, 30 Dec 2024 19:23:26 -0800	[thread overview]
Message-ID: <20241230192326.384fd21d@kernel.org> (raw)
In-Reply-To: <20241230141435.2817079-1-gur.stavi@huawei.com>

On Mon, 30 Dec 2024 16:14:35 +0200 Gur Stavi wrote:
> > > 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.  
> >
> > Don't misquote me. You did it in your previous reply, now you're doing
> > it again.
> >
> > If you don't understand what I'm saying you can ask for clarifications.
> 
> We studied previous submissions and followed their example.
> Were the maintainers wrong to approve Amazon and Microsoft drivers?

It's not a right or wrong question, more a cost/benefit question.
I'm not sure the community benefits from merging every single company's
paravirt driver, when virtio exists. I'd say having those drivers
upstream is somewhere around neutral.

BTW very often guidance for new drivers is set by problems with already
merged drivers. Not that it's necessarily the case here, just sharing
some general knowledge about the upstream process.

> I don't understand what the problem is. Please clarify.

Primarily the fact that you keep arguing as if joining the community
was done by winning a fight. If annotating HW structures with endian
is beyond your / your teams capabilities, that's okay, just replace
the "will not be converted" with "are currently not converted" in 
the comment.

For your reference here are the development stats showing that
Huawei is the biggest net-taker of code reviews in networking:
https://lore.kernel.org/all/20241119191608.514ea226@kernel.org/

  reply	other threads:[~2024-12-31  3:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-19  9:21 [PATCH net-next v01 0/1] net: hinic3: Add a driver for Huawei 3rd gen NIC Gur Stavi
2024-12-19  9:21 ` [PATCH net-next v01 1/1] hinic3: module initialization and tx/rx logic Gur Stavi
2024-12-20 21:24   ` Jakub Kicinski
2024-12-22  8:12     ` Gur Stavi
2024-12-23 15:39       ` Jakub Kicinski
2024-12-25 12:56         ` Gur Stavi
2024-12-27 18:31           ` Jakub Kicinski
2024-12-30 14:14             ` Gur Stavi
2024-12-31  3:23               ` Jakub Kicinski [this message]
2025-01-01  6:49                 ` Gur Stavi

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=20241230192326.384fd21d@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=cai.huoqing@linux.dev \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gongfan1@huawei.com \
    --cc=guoxin09@huawei.com \
    --cc=gur.stavi@huawei.com \
    --cc=helgaas@kernel.org \
    --cc=horms@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=meny.yossefi@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shenchenyang1@hisilicon.com \
    --cc=shijing34@huawei.com \
    --cc=wulike1@huawei.com \
    --cc=zhoushuai28@huawei.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;
as well as URLs for NNTP newsgroup(s).