________________________________
From: Jakub Kicinski <kuba@kernel.org>
Sent: Thursday, November 25, 2021 8:38 PM
To: Radha Mohan <redacted>
Cc: netdev@vger.kernel.org <redacted>; David S. Miller <davem@davemloft.net>; Sunil Kovvuri Goutham <sgoutham@marvell.com>
Subject: [EXT] Re: [PATCH] octeontx2-nicvf: Add netdev interface support for SDP VF devices
External Email
----------------------------------------------------------------------
On Wed, 24 Nov 2021 22:00:49 -0800 Radha Mohan wrote:
quoted
On Wed, Nov 24, 2021 at 7:27 PM Jakub Kicinski [off-list ref] wrote:
quoted
On Wed, 24 Nov 2021 18:21:04 -0800 Radha Mohan wrote:
quoted
This patch adds netdev interface for SDP VFs. This interface can be used
to communicate with a host over PCIe when OcteonTx is in PCIe Endpoint
mode.
All your SDP/SDK/management interfaces do not fit into our netdev
model of the world and should be removed upstream.
SDP is our System DMA Packet Interface which sends/receives network
packets to NIX block. It is similar to CGX, LBK blocks but only
difference is the medium being PCIe. So if you have accepted that I
believe you can accept this as well.
Nope, I have not accepted that. I was just too lazy to send a revert
after it was merged.
What is the objection here ?
Is kernel netdev not supposed to be used with-in end-point ?
If customers want to use upstream kernel with-in endpoint and not
proprietary SDK, why to impose restrictions.
Thanks,
Sunil.
On Fri, 26 Nov 2021 09:44:10 +0530 Sunil Kovvuri wrote:
quoted
Nope, I have not accepted that. I was just too lazy to send a revert
after it was merged.
What is the objection here ?
Is kernel netdev not supposed to be used with-in end-point ?
Yes.
If customers want to use upstream kernel with-in endpoint and not
proprietary SDK, why to impose restrictions.
Because our APIs and interfaces have associated semantics. That's
the primary thing we care about upstream. You need to use or create
standard interfaces, not come up with your own thing and retrofit it
into one of the APIs. Not jam PTP configuration thru devlink params,
or use netdevs to talk to your FW because its convenient. Trust me,
you're not the first one to come up with this idea.
Frankly if the octeontx2 team continues on its current path I think
the driver should be removed. You bring no benefit to the community
I don't see why we'd give you the time of day.
On Fri, Nov 26, 2021 at 10:28 AM Jakub Kicinski [off-list ref] wrote:
On Fri, 26 Nov 2021 09:44:10 +0530 Sunil Kovvuri wrote:
quoted
quoted
Nope, I have not accepted that. I was just too lazy to send a revert
after it was merged.
What is the objection here ?
Is kernel netdev not supposed to be used with-in end-point ?
Yes.
If you don't mind can you please write these rules somewhere and push
to kernel documentation.
So that we are clear on what restrictions kernel netdev imposes.
quoted
If customers want to use upstream kernel with-in endpoint and not
proprietary SDK, why to impose restrictions.
Because our APIs and interfaces have associated semantics. That's
the primary thing we care about upstream. You need to use or create
standard interfaces, not come up with your own thing and retrofit it
into one of the APIs. Not jam PTP configuration thru devlink params,
or use netdevs to talk to your FW because its convenient. Trust me,
you're not the first one to come up with this idea.
I see that you are just assuming how it's used and making comments.
In scenarios where OcteonTx2 is used as a offload card (DPU) or VRAN,
some of the pkts
will be sent to host for processing. This path is used to forward such
pkts to host and viceversa.
It's not for internal communication between host and firmware.
It's using the standard netdev interfaces, APIs and network stack
packet forwarding.
I don't understand what's wrong with this.
The devlink params are being used across drivers to do proprietary HW settings.
There is no PTP protocol or pkt related configuration that's being
jammed through in the other patch.
Frankly if the octeontx2 team continues on its current path I think
the driver should be removed. You bring no benefit to the community
I don't see why we'd give you the time of day.
That's an unnecessary comment crossing the lines.
Thanks,
Sunil.
On Fri, 26 Nov 2021 10:51:24 +0530 Sunil Kovvuri wrote:
On Fri, Nov 26, 2021 at 10:28 AM Jakub Kicinski [off-list ref] wrote:
quoted
On Fri, 26 Nov 2021 09:44:10 +0530 Sunil Kovvuri wrote:
quoted
What is the objection here ?
Is kernel netdev not supposed to be used with-in end-point ?
Yes.
If you don't mind can you please write these rules somewhere and push
to kernel documentation.
So that we are clear on what restrictions kernel netdev imposes.
Kernel develops by precedent. You're making a precedent with your
patches and have not bothered documenting it. In fact there isn't
even a proper commit message.
quoted
quoted
If customers want to use upstream kernel with-in endpoint and not
proprietary SDK, why to impose restrictions.
Because our APIs and interfaces have associated semantics. That's
the primary thing we care about upstream. You need to use or create
standard interfaces, not come up with your own thing and retrofit it
into one of the APIs. Not jam PTP configuration thru devlink params,
or use netdevs to talk to your FW because its convenient. Trust me,
you're not the first one to come up with this idea.
I see that you are just assuming how it's used and making comments.
In scenarios where OcteonTx2 is used as a offload card (DPU) or VRAN,
some of the pkts
will be sent to host for processing. This path is used to forward such
pkts to host and viceversa.
It's not for internal communication between host and firmware.
Sounds like you should be implementing the switchdev model, then.
It's using the standard netdev interfaces, APIs and network stack
packet forwarding.
I don't understand what's wrong with this.
Again, upstream comes with expectations around semantics of objects
and modeling.
The devlink params are being used across drivers to do proprietary
HW settings. There is no PTP protocol or pkt related configuration
that's being jammed through in the other patch.
I don't even know how to respond to this. And guess what, PTP is
relatively well documented, which clearly proves that your "please
document.." request is empty rhetoric.
quoted
Frankly if the octeontx2 team continues on its current path I think
the driver should be removed. You bring no benefit to the community
I don't see why we'd give you the time of day.
That's an unnecessary comment crossing the lines.
I'm not sure why. Please elucidate how working with your team is
bringing any benefit to the community.