public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Justin Lai <justinlai0215@realtek.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"jiri@resnulli.us" <jiri@resnulli.us>,
	"horms@kernel.org" <horms@kernel.org>,
	"rkannoth@marvell.com" <rkannoth@marvell.com>,
	"Ping-Ke Shih" <pkshih@realtek.com>,
	Larry Chiu <larry.chiu@realtek.com>
Subject: RE: [PATCH net-next v20 10/13] rtase: Implement ethtool function
Date: Mon, 17 Jun 2024 06:54:59 +0000	[thread overview]
Message-ID: <82ea81963af9482aa45d0463a21956b5@realtek.com> (raw)
In-Reply-To: <20240612173505.095c4117@kernel.org>

> On Fri, 7 Jun 2024 16:43:18 +0800 Justin Lai wrote:
> > Implement the ethtool function to support users to obtain network card
> > information, including obtaining various device settings, Report
> > whether physical link is up, Report pause parameters, Set pause
> > parameters, Return a set of strings that describe the requested
> > objects, Get number of strings that @get_strings will write, Return
> > extended statistics about the device.
> 
> You don't implement get_strings any more.

Sorry, I will modify it.

> 
> > +static void rtase_get_drvinfo(struct net_device *dev,
> > +                           struct ethtool_drvinfo *drvinfo) {
> > +     const struct rtase_private *tp = netdev_priv(dev);
> > +
> > +     strscpy(drvinfo->driver, KBUILD_MODNAME, 32);
> 
> sizeof(drvinfo->driver) instead of the literal 32?

It seems like a better approach, I'll switch to using
sizeof(drvinfo->driver), thank you.

> 
> > +     strscpy(drvinfo->bus_info, pci_name(tp->pdev), 32);
> 
> Can you double check that overwriting these fields is actually needed?
> I think core will fill this in for you in ethtool_get_drvinfo()

I have removed this line of code for testing. Before removing the code,
I could obtain bus info by entering "ethtool -i". However, after removing
the code, entering "ethtool -i" no longer retrieves the bus info.
Therefore, I believe that this line of code is still necessary.

> 
> > +     if ((value & (RTASE_FORCE_TXFLOW_EN |
> RTASE_FORCE_RXFLOW_EN)) ==
> > +         (RTASE_FORCE_TXFLOW_EN | RTASE_FORCE_RXFLOW_EN)) {
> > +             pause->rx_pause = 1;
> > +             pause->tx_pause = 1;
> > +     } else if ((value & RTASE_FORCE_TXFLOW_EN)) {
> 
> unnecessary parenthesis
> 
> > +             pause->tx_pause = 1;
> > +     } else if ((value & RTASE_FORCE_RXFLOW_EN)) {
> 
> same here
> 

Sorry, I will remove the unnecessary parentheses, thank you.

> > +             pause->rx_pause = 1;
> > +     }
> > +}
> > +
> > +static int rtase_set_pauseparam(struct net_device *dev,
> > +                             struct ethtool_pauseparam *pause) {
> > +     const struct rtase_private *tp = netdev_priv(dev);
> > +     u16 value = rtase_r16(tp, RTASE_CPLUS_CMD);
> > +
> > +     if (pause->autoneg)
> > +             return -EOPNOTSUPP;
> > +
> > +     value &= ~(RTASE_FORCE_TXFLOW_EN |
> RTASE_FORCE_RXFLOW_EN);
> > +
> > +     if (pause->tx_pause)
> > +             value |= RTASE_FORCE_TXFLOW_EN;
> > +
> > +     if (pause->rx_pause)
> > +             value |= RTASE_FORCE_RXFLOW_EN;
> > +
> > +     rtase_w16(tp, RTASE_CPLUS_CMD, value);
> > +     return 0;
> > +}
> > +
> > +static void rtase_get_eth_mac_stats(struct net_device *dev,
> > +                                 struct ethtool_eth_mac_stats
> *stats)
> > +{
> > +     struct rtase_private *tp = netdev_priv(dev);
> > +     const struct rtase_counters *counters;
> > +
> > +     counters = tp->tally_vaddr;
> > +     if (!counters)
> 
> you fail probe if this is NULL, why check if here?
> 

Sorry, this check seems unnecessary, I will remove it.

> > +             return;
> > +
> > +     rtase_dump_tally_counter(tp);
> > +
> > +     stats->FramesTransmittedOK = le64_to_cpu(counters->tx_packets);
> > +     stats->SingleCollisionFrames =
> le32_to_cpu(counters->tx_one_collision);
> > +     stats->MultipleCollisionFrames =
> > +             le32_to_cpu(counters->tx_multi_collision);
> > +     stats->FramesReceivedOK = le64_to_cpu(counters->rx_packets);
> > +     stats->FrameCheckSequenceErrors =
> > + le32_to_cpu(counters->rx_errors);
> 
> You dont report this in rtase_get_stats64() as crc errors, are these really CRC /
> FCS errors or other errors?

Our rx_error indeed refers to crc_error. I will assign the value of
rx_error to the crc_error in rtase_get_stats64().

> 
> > +     stats->AlignmentErrors = le16_to_cpu(counters->align_errors);
> > +     stats->FramesAbortedDueToXSColls =
> le16_to_cpu(counters->tx_aborted);
> > +     stats->FramesLostDueToIntMACXmitError =
> > +             le64_to_cpu(counters->tx_errors);
> > +     stats->FramesLostDueToIntMACRcvError =
> > +             le16_to_cpu(counters->rx_missed);
> 
> Are you sure this is the correct statistic to report as?
> What's the definition of rx_missed in the datasheet?

What we refer to as rx miss is the packets that can't be received because
the fifo in the MAC is full. We consider this a type of MAC error, identical
to the definition of FramesLostDueToIntMACRcvError.

> 
> Also is 16 bits enough for a packet counter at 5Gbps?
> Don't you have to periodically accumulate this counter so that it doesn't wrap
> around?

Indeed, this counter may wrap, but we don't need to accumulate it, because
an increase in the number of rx_miss largely indicates that the system
processing speed is not fast enough. Therefore, the size of this counter
doesn't need to be too large.

> 
> > +     stats->MulticastFramesReceivedOK =
> le32_to_cpu(counters->rx_multicast);
> > +     stats->BroadcastFramesReceivedOK =
> > +le64_to_cpu(counters->rx_broadcast);
> > +}
> > +
> > +static const struct ethtool_ops rtase_ethtool_ops = {
> > +     .get_drvinfo = rtase_get_drvinfo,
> > +     .get_link = ethtool_op_get_link,
> > +     .get_link_ksettings = rtase_get_settings,
> > +     .get_pauseparam = rtase_get_pauseparam,
> > +     .set_pauseparam = rtase_set_pauseparam,
> > +     .get_eth_mac_stats = rtase_get_eth_mac_stats,
> > +     .get_ts_info = ethtool_op_get_ts_info, };
> > +
> >  static void rtase_init_netdev_ops(struct net_device *dev)  {
> >       dev->netdev_ops = &rtase_netdev_ops;
> > +     dev->ethtool_ops = &rtase_ethtool_ops;
> >  }
> >
> >  static void rtase_reset_interrupt(struct pci_dev *pdev,


  reply	other threads:[~2024-06-17  6:55 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07  8:43 [PATCH net-next v20 00/13] Add Realtek automotive PCIe driver Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 01/13] rtase: Add pci table supported in this module Justin Lai
2024-06-13  9:01   ` Markus Elfring
2024-06-17  8:14     ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 02/13] rtase: Implement the .ndo_open function Justin Lai
2024-06-13  7:50   ` Markus Elfring
2024-06-17  9:25     ` Justin Lai
2024-06-17 10:07       ` [v20 " Markus Elfring
2024-06-17 13:28         ` Justin Lai
2024-06-17 18:59           ` Simon Horman
2024-06-17 20:22             ` Markus Elfring
2024-06-18  7:51             ` Justin Lai
     [not found]             ` <202406181007.45IA7eWxA3305754@rtits1.realtek.com.tw>
2024-06-18 11:01               ` Justin Lai
2024-06-18 11:30                 ` Markus Elfring
2024-06-07  8:43 ` [PATCH net-next v20 03/13] rtase: Implement the rtase_down function Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 04/13] rtase: Implement the interrupt routine and rtase_poll Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 05/13] rtase: Implement hardware configuration function Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 06/13] rtase: Implement .ndo_start_xmit function Justin Lai
2024-06-07  9:03   ` Hariprasad Kelam
2024-06-12  4:35     ` Justin Lai
2024-06-12 10:36       ` Hariprasad Kelam
2024-06-13  3:38         ` Justin Lai
2024-06-13  7:24           ` Hariprasad Kelam
2024-06-07 15:54   ` Ratheesh Kannoth
2024-06-12  4:20     ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 07/13] rtase: Implement a function to receive packets Justin Lai
2024-06-13  0:43   ` Jakub Kicinski
2024-06-17  6:44     ` Justin Lai
2024-06-17 15:02       ` Jakub Kicinski
2024-06-18  3:40         ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 08/13] rtase: Implement net_device_ops Justin Lai
2024-06-13  0:39   ` Jakub Kicinski
2024-06-13  3:16     ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 09/13] rtase: Implement pci_driver suspend and resume function Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 10/13] rtase: Implement ethtool function Justin Lai
2024-06-13  0:35   ` Jakub Kicinski
2024-06-17  6:54     ` Justin Lai [this message]
2024-06-17 14:07       ` Andrew Lunn
2024-06-18  9:56         ` Justin Lai
2024-06-17 15:10       ` Jakub Kicinski
2024-06-18  7:28         ` Justin Lai
2024-06-18 14:24           ` Jakub Kicinski
2024-06-19  3:40             ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 11/13] rtase: Add a Makefile in the rtase folder Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 12/13] realtek: Update the Makefile and Kconfig in the realtek folder Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 13/13] MAINTAINERS: Add the rtase ethernet driver entry Justin Lai

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=82ea81963af9482aa45d0463a21956b5@realtek.com \
    --to=justinlai0215@realtek.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=larry.chiu@realtek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pkshih@realtek.com \
    --cc=rkannoth@marvell.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