Message-ID: <6b6deed6193c4e0082f0eaaa9b92171d@realtek.com>
Date: Mon, 29 Jul 2024 12:26:26 +0000
From: Justin Lai <justinlai0215@...ltek.com>
To: Joe Damato <jdamato@...tly.com>
CC: "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net"
	<davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "jiri@...nulli.us" <jiri@...nulli.us>,
        "horms@...nel.org" <horms@...nel.org>,
        "rkannoth@...vell.com" <rkannoth@...vell.com>,
        Ping-Ke Shih
	<pkshih@...ltek.com>,
        Larry Chiu <larry.chiu@...ltek.com>
Subject: RE: [PATCH net-next v25 08/13] rtase: Implement net_device_ops

> On Mon, Jul 29, 2024 at 11:39:03AM +0000, Justin Lai wrote:
> > > On Mon, Jul 29, 2024 at 02:21:16PM +0800, Justin Lai wrote:
> > > > 1. Implement .ndo_set_rx_mode so that the device can change
> > > > address list filtering.
> > > > 2. Implement .ndo_set_mac_address so that mac address can be
> changed.
> > > > 3. Implement .ndo_change_mtu so that mtu can be changed.
> > > > 4. Implement .ndo_tx_timeout to perform related processing when
> > > > the transmitter does not make any progress.
> > > > 5. Implement .ndo_get_stats64 to provide statistics that are
> > > > called when the user wants to get network device usage.
> > > > 6. Implement .ndo_vlan_rx_add_vid to register VLAN ID when the
> > > > device supports VLAN filtering.
> > > > 7. Implement .ndo_vlan_rx_kill_vid to unregister VLAN ID when the
> > > > device supports VLAN filtering.
> > > > 8. Implement the .ndo_setup_tc to enable setting any "tc"
> > > > scheduler, classifier or action on dev.
> > > > 9. Implement .ndo_fix_features enables adjusting requested feature
> > > > flags based on device-specific constraints.
> > > > 10. Implement .ndo_set_features enables updating device
> > > > configuration to new features.
> > > >
> > > > Signed-off-by: Justin Lai <justinlai0215@...ltek.com>
> > > > ---
> > > >  .../net/ethernet/realtek/rtase/rtase_main.c   | 235
> ++++++++++++++++++
> > > >  1 file changed, 235 insertions(+)
> > > >
> > > > diff --git a/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > > > b/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > > > index 8fd69d96219f..80673fa1e9a3 100644
> > >
> > > [...]
> > >
> > > > +static void rtase_dump_state(const struct net_device *dev) {
> > >
> > > [...]
> > >
> > > > +
> > > > +     netdev_err(dev, "tx_packets %lld\n",
> > > > +                le64_to_cpu(counters->tx_packets));
> > > > +     netdev_err(dev, "rx_packets %lld\n",
> > > > +                le64_to_cpu(counters->rx_packets));
> > > > +     netdev_err(dev, "tx_errors %lld\n",
> > > > +                le64_to_cpu(counters->tx_errors));
> > > > +     netdev_err(dev, "rx_errors %d\n",
> > > > +                le32_to_cpu(counters->rx_errors));
> > > > +     netdev_err(dev, "rx_missed %d\n",
> > > > +                le16_to_cpu(counters->rx_missed));
> > > > +     netdev_err(dev, "align_errors %d\n",
> > > > +                le16_to_cpu(counters->align_errors));
> > > > +     netdev_err(dev, "tx_one_collision %d\n",
> > > > +                le32_to_cpu(counters->tx_one_collision));
> > > > +     netdev_err(dev, "tx_multi_collision %d\n",
> > > > +                le32_to_cpu(counters->tx_multi_collision));
> > > > +     netdev_err(dev, "rx_unicast %lld\n",
> > > > +                le64_to_cpu(counters->rx_unicast));
> > > > +     netdev_err(dev, "rx_broadcast %lld\n",
> > > > +                le64_to_cpu(counters->rx_broadcast));
> > > > +     netdev_err(dev, "rx_multicast %d\n",
> > > > +                le32_to_cpu(counters->rx_multicast));
> > > > +     netdev_err(dev, "tx_aborted %d\n",
> > > > +                le16_to_cpu(counters->tx_aborted));
> > > > +     netdev_err(dev, "tx_underun %d\n",
> > > > +                le16_to_cpu(counters->tx_underun));
> > >
> > > You use le64/32/16_to_cpu here for all stats, but below in
> > > rtase_get_stats64, it is only used for tx_errors.
> > >
> > > The code should probably be consistent? Either you do or don't need
> > > to use them?
> > >
> > > > +}
> > > > +
> > > [...]
> > > > +
> > > > +static void rtase_get_stats64(struct net_device *dev,
> > > > +                           struct rtnl_link_stats64 *stats) {
> > > > +     const struct rtase_private *tp = netdev_priv(dev);
> > > > +     const struct rtase_counters *counters;
> > > > +
> > > > +     counters = tp->tally_vaddr;
> > > > +
> > > > +     dev_fetch_sw_netstats(stats, dev->tstats);
> > > > +
> > > > +     /* fetch additional counter values missing in stats collected by
> driver
> > > > +      * from tally counter
> > > > +      */
> > > > +     rtase_dump_tally_counter(tp);
> > > > +     stats->rx_errors = tp->stats.rx_errors;
> > > > +     stats->tx_errors = le64_to_cpu(counters->tx_errors);
> > > > +     stats->rx_dropped = tp->stats.rx_dropped;
> > > > +     stats->tx_dropped = tp->stats.tx_dropped;
> > > > +     stats->multicast = tp->stats.multicast;
> > > > +     stats->rx_length_errors = tp->stats.rx_length_errors;
> > >
> > > See above; le64_to_cpu for tx_errors, but not the rest of the stats. Why?
> >
> > The rtase_dump_state() function is primarily used to dump certain
> > hardware information. Following discussions with Jakub, it was
> > suggested that we should design functions to accumulate the 16-bit and
> > 32-bit counter values to prevent potential overflow issues due to the
> > limited size of the counters. However, the final decision was to
> > temporarily refrain from reporting 16-bit and 32-bit counter
> > information. Additionally, since tx_packet and rx_packet data are
> > already provided through tstat, we ultimately opted to modify it to the
> current rtase_get_stats64() function.
> 
> Your response was a bit confusing, but after re-reading the code I think I
> understand now that I misread the code above.
> 
> The answer seems to be that tx_errors is accumulated in rtase_counters
> (which needs le*_to_cpu), but the other counters are accumulated in tp->stats
> which do not need le*_to_cpu because they are already being accounted in
> whatever endianness the CPU uses.
> 
> OK.

I apologize for misunderstanding your question earlier. However, your
current understanding is correct.

Thanks
Justin

Powered by blists - more mailing lists