All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	Oleksij Rempel <o.rempel@pengutronix.de>,
	Tristram.Ha@microchip.com,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Simon Horman <horms@kernel.org>,
	Dan Carpenter <dan.carpenter@linaro.org>,
	"Ricardo B. Marliere" <ricardo@marliere.net>,
	Casper Andersson <casper.casan@gmail.com>,
	linux-kernel@vger.kernel.org,
	Woojung Huh <woojung.huh@microchip.com>,
	UNGLinuxDriver@microchip.com, Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH v2 net-next] net: dsa: Allow only up to two HSR HW offloaded ports for KSZ9477
Date: Fri, 21 Jun 2024 10:31:44 +0200	[thread overview]
Message-ID: <20240621103144.300a2c89@wsk> (raw)
In-Reply-To: <20240620143306.f6x25tqksatccqwf@skbuf>

[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]

Hi Vladimir,

> On Thu, Jun 20, 2024 at 03:28:19PM +0200, Lukasz Majewski wrote:
> > I don't have xrs700x to test. Shall I spend time on fixing some
> > perceived issue for IC which I don't have?
> > 
> > Maybe somebody (like manufacturer or _real_ user) with xrc700x shall
> > test the code and provide feedback?  
> 
> One of the basic premises when you introduce a new core feature with
> offload potential is that you consider how the existing drivers will
> handle it. Either they do something reasonable already (great but
> rarely happens), or they refuse offloading the new feature until, as
> you say, the developer or real user has a look at what would be
> needed. Once you get things to that stage, that would be, in my mind,
> the cutoff point between the responsibility of who's adding the core
> feature and who's interested in it on random other hardware.
> 
> Sometimes, the burden of checking/modifying all existing offloading
> drivers before adding a new feature is so high, that some offloading
> API is developed with an opt-in rather than opt-out model. AKA,
> rather than the configuration being directly given to you and you
> rejecting what you don't support, the core first assumed you can't
> offload anything, and you have to set a bit from the driver to
> announce the core that you can. qdisc_offload_query_caps() is an
> implementation of this model, though I'm pretty sure the
> NETDEV_CHANGEUPPER notifier doesn't have anything similar currently.
> 

Thanks for the explanation.

> That being said, I think the responsibility falls on your side here,
> given that you introduced a new HSR port type and offload drivers
> still implicitly think it's a ring port, because there's no API to
> tell them otherwise.

IMHO, the above problem is not related to the patch send here. It shall
be addressed with new patch series.

> 
> This is not to take away from the good things you _have_ done already.




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2024-06-21  8:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-19 13:42 [PATCH v2 net-next] net: dsa: Allow only up to two HSR HW offloaded ports for KSZ9477 Lukasz Majewski
2024-06-19 13:54 ` Dan Carpenter
2024-06-19 14:27 ` Andrew Lunn
2024-06-19 14:42 ` Vladimir Oltean
2024-06-19 15:10   ` Lukasz Majewski
2024-06-19 15:48     ` Vladimir Oltean
2024-06-19 15:59       ` Vladimir Oltean
2024-06-20  7:59         ` Lukasz Majewski
2024-06-20  9:02           ` Vladimir Oltean
2024-06-20 12:00             ` Lukasz Majewski
2024-06-20 12:06               ` Vladimir Oltean
2024-06-20 13:28                 ` Lukasz Majewski
2024-06-20 14:33                   ` Vladimir Oltean
2024-06-21  8:31                     ` Lukasz Majewski [this message]
2024-06-21  8:43                       ` Vladimir Oltean
2024-06-19 21:54       ` Vladimir Oltean

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=20240621103144.300a2c89@wsk \
    --to=lukma@denx.de \
    --cc=Tristram.Ha@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=bigeasy@linutronix.de \
    --cc=casper.casan@gmail.com \
    --cc=dan.carpenter@linaro.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=ricardo@marliere.net \
    --cc=woojung.huh@microchip.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.