[net-next,0/9] CN10KB MAC block support

  The nextgen silicon CN10KB supports new MAC block RPM2
and has a variable number of LMACS. This series of patches
defines new mac_ops and configures csrs specific to new
MAC.

Defines new mailbox support to Reset LMAC stats, read
FEC stats and set Physical state such that PF netdev
can use mailbox support to use the features.

Extends debugfs support for MAC block to show dropped
packets by DMAC filters and show FEC stats

Hariprasad Kelam (5):
  octeontx2-af: Support More number of MAC blocks
  octeontx2-af: CN10KB MAC RPM_100/USX support
  octeontx2-af: Reset MAC specific csrs on FLR
  octeontx2-af: Show count of dropped packets by DMAC filters
  octeontx2-af: Add support for RPM FEC stats

Naveen Mamindlapalli (1):
  octeontx2-af: Add proper return codes for AF mbox handlers

Revital Regev (1):
  octeontx2-af: Reset MAC block RX/TX statistics

Vamsi Attunuru (1):
  octeontx2-af: physical link state change

Vidhya Vidhyaraman (1):
  octeontx2-af: Add programmed macaddr to RVU pfvf

 .../net/ethernet/marvell/octeontx2/af/cgx.c   | 169 ++++++++--
 .../net/ethernet/marvell/octeontx2/af/cgx.h   |  15 +-
 .../marvell/octeontx2/af/lmac_common.h        |  19 +-
 .../net/ethernet/marvell/octeontx2/af/mbox.h  |   8 +
 .../net/ethernet/marvell/octeontx2/af/rpm.c   | 298 ++++++++++++++++--
 .../net/ethernet/marvell/octeontx2/af/rpm.h   |  42 ++-
 .../net/ethernet/marvell/octeontx2/af/rvu.c   |   1 +
 .../net/ethernet/marvell/octeontx2/af/rvu.h   |  14 +-
 .../ethernet/marvell/octeontx2/af/rvu_cgx.c   | 193 +++++++++---
 .../marvell/octeontx2/af/rvu_debugfs.c        |  16 +-
 .../ethernet/marvell/octeontx2/af/rvu_nix.c   |  10 +-
 .../marvell/octeontx2/af/rvu_npc_hash.c       |   2 +-
 12 files changed, 667 insertions(+), 120 deletions(-)

--
2.17.1
  

On Sat, 12 Nov 2022 10:01:32 +0530 Hariprasad Kelam wrote:
> The nextgen silicon CN10KB supports new MAC block RPM2
> and has a variable number of LMACS. This series of patches
> defines new mac_ops and configures csrs specific to new
> MAC.
> 
> Defines new mailbox support to Reset LMAC stats, read
> FEC stats and set Physical state such that PF netdev
> can use mailbox support to use the features.
> 
> Extends debugfs support for MAC block to show dropped
> packets by DMAC filters and show FEC stats

I personally see no reason for us to keep merging your AF patches.
Upstream is for working together and there is no synergy between
your code, other drivers and the user APIs we build. Why not just 
keep it out of tree?
  

On Fri, Nov 11, 2022 at 09:12:35PM -0800, Jakub Kicinski wrote:
> On Sat, 12 Nov 2022 10:01:32 +0530 Hariprasad Kelam wrote:
> > The nextgen silicon CN10KB supports new MAC block RPM2
> > and has a variable number of LMACS. This series of patches
> > defines new mac_ops and configures csrs specific to new
> > MAC.
> > 
> > Defines new mailbox support to Reset LMAC stats, read
> > FEC stats and set Physical state such that PF netdev
> > can use mailbox support to use the features.
> > 
> > Extends debugfs support for MAC block to show dropped
> > packets by DMAC filters and show FEC stats
> 
> I personally see no reason for us to keep merging your AF patches.
> Upstream is for working together and there is no synergy between
> your code, other drivers and the user APIs we build. Why not just 
> keep it out of tree?

Yes, see my comment about the ethtool .get_fec_stats. Maybe it is
there, hidden amongst all the code, but it is not obvious.

If you do want to stay in tree, may i suggest you move all your
statistics in your debugfs to official kernel APIs, and then remove
them from debugfs. This might require you work with the community to
extend the current APIs, which is the synergy thing Jakub is taking
about.

	Andrew
  

On Fri, Nov 11, 2022 at 09:12:35PM -0800, Jakub Kicinski wrote:
> On Sat, 12 Nov 2022 10:01:32 +0530 Hariprasad Kelam wrote:
> > The nextgen silicon CN10KB supports new MAC block RPM2 and has a 
> > variable number of LMACS. This series of patches defines new mac_ops 
> > and configures csrs specific to new MAC.
> > 
> > Defines new mailbox support to Reset LMAC stats, read FEC stats and 
> > set Physical state such that PF netdev can use mailbox support to 
> > use the features.
> > 
> > Extends debugfs support for MAC block to show dropped packets by 
> > DMAC filters and show FEC stats
> 
> I personally see no reason for us to keep merging your AF patches.
> Upstream is for working together and there is no synergy between your 
> code, other drivers and the user APIs we build. Why not just keep it 
> out of tree?

Yes, see my comment about the ethtool .get_fec_stats. Maybe it is there, hidden amongst all the code, but it is not obvious.

If you do want to stay in tree, may i suggest you move all your statistics in your debugfs to official kernel APIs, and then remove them from debugfs. This might require you work with the community to extend the current APIs, which is the synergy thing Jakub is taking about.

	Andrew


This patch series adds two debugfs entries, one for FEC stats and other to show "Dropped packets by DMAC filters".

For FEC stats will remove debugfs entry and integrate to ethtool API in the next version.

For  "Dropped packets by DMAC filters" did not find any equivalent APIs, so will keep it as is.
  

> For  "Dropped packets by DMAC filters" did not find any equivalent APIs, so will keep it as is.

Nope. Propose a generic netlink API, probably as an extension to
ethtool, which other vendors can use as well.

This is exactly Jakub and my point. Is your hardware so special it
does things which no other vendor does? Is the concept of DMAC filters
dropping packets unique to your hardware? Is this feature so obscure
that no other vendor will ever implement it? And if it is that
obscure, is any user actually going to use it?

	Andrew
  

> For  "Dropped packets by DMAC filters" did not find any equivalent APIs, so will keep it as is.

>> Nope. Propose a generic netlink API, probably as an extension to ethtool, which other vendors can use as well.

ACK,  will remove DMAC filters debugfs from this patch set and will submit this change with netlink API in separate set.


This is exactly Jakub and my point. Is your hardware so special it does things which no other vendor does? Is the concept of DMAC filters dropping packets unique to your hardware? Is this feature so obscure that no other vendor will ever implement it? And if it is that obscure, is any user actually going to use it?

	Andrew