On Wed, 2 Dec 2020 02:28:51 +0200 Vladimir Oltean wrote:
> On Fri, Nov 27, 2020 at 10:36:42PM +0100, Andrew Lunn wrote:
> > > Either way, can we conclude that ndo_get_stats64 is not a replacement
> > > for ethtool -S, since the latter is blocking and, if implemented
> > > correctly,
> > > can retu
Hi Jakub,
On Fri, Nov 27, 2020 at 10:36:42PM +0100, Andrew Lunn wrote:
> > Either way, can we conclude that ndo_get_stats64 is not a replacement
> > for ethtool -S, since the latter is blocking and, if implemented correctly,
> > can return the counters at the time of the call (therefore making sur
On Mon, Nov 30, 2020 at 05:58:17PM -0600, George McCollister wrote:
> On Mon, Nov 30, 2020 at 5:50 PM Vladimir Oltean wrote:
> >
> > On Mon, Nov 30, 2020 at 10:52:35AM -0600, George McCollister wrote:
> > > Another possible option could be replacing for_each_netdev_rcu with
> > > for_each_netdev_s
On Mon, Nov 30, 2020 at 5:50 PM Vladimir Oltean wrote:
>
> On Mon, Nov 30, 2020 at 10:52:35AM -0600, George McCollister wrote:
> > Another possible option could be replacing for_each_netdev_rcu with
> > for_each_netdev_srcu and using list_for_each_entry_srcu (though it's
> > currently used nowhere
On Mon, Nov 30, 2020 at 10:52:35AM -0600, George McCollister wrote:
> Another possible option could be replacing for_each_netdev_rcu with
> for_each_netdev_srcu and using list_for_each_entry_srcu (though it's
> currently used nowhere else in the kernel). Has anyone considered
> using sleepable RCUs
On Fri, Nov 27, 2020 at 8:15 PM Jakub Kicinski wrote:
>
> On Sat, 28 Nov 2020 03:41:06 +0200 Vladimir Oltean wrote:
> > Jakub, I would like to hear more from you. I would still like to try
> > this patch out. You clearly have a lot more background with the code.
>
> Well, I've seen people run into
On Sat, 28 Nov 2020 03:41:06 +0200 Vladimir Oltean wrote:
> Jakub, I would like to hear more from you. I would still like to try
> this patch out. You clearly have a lot more background with the code.
Well, I've seen people run into the problem of this NDO not being able
to sleep, but I don't have
On Fri, Nov 27, 2020 at 03:56:49PM -0800, Jakub Kicinski wrote:
> What is it with my email today, didn't get this one again.
>
> On Sat, 28 Nov 2020 01:39:16 +0200 Vladimir Oltean wrote:
> > On Sat, Nov 28, 2020 at 12:30:48AM +0100, Andrew Lunn wrote:
> > > > If there is a better alternative I'm al
On Sat, Nov 28, 2020 at 01:39:12AM +0100, Andrew Lunn wrote:
> > This means, as far as I understand, 2 things:
> > 1. call_netdevice_notifiers_info doesn't help, since our problem is the
> >same
> > 2. I think that holding the RTNL should also be a valid way to iterate
> >through the net de
> This means, as far as I understand, 2 things:
> 1. call_netdevice_notifiers_info doesn't help, since our problem is the
>same
> 2. I think that holding the RTNL should also be a valid way to iterate
>through the net devices in the current netns, and doing just that
>could be the simpl
> If there is a better alternative I'm all ears but having /proc and
> ifconfig return zeros for error counts while ip link doesn't will lead
> to too much confusion IMO. While delayed update of stats is a fact of
> life for _years_ now (hence it was backed into the ethtool -C API).
How about dev_
On Sat, Nov 28, 2020 at 01:39:16AM +0200, Vladimir Oltean wrote:
> On Sat, Nov 28, 2020 at 12:30:48AM +0100, Andrew Lunn wrote:
> > > If there is a better alternative I'm all ears but having /proc and
> > > ifconfig return zeros for error counts while ip link doesn't will lead
> > > to too much con
What is it with my email today, didn't get this one again.
On Sat, 28 Nov 2020 01:39:16 +0200 Vladimir Oltean wrote:
> On Sat, Nov 28, 2020 at 12:30:48AM +0100, Andrew Lunn wrote:
> > > If there is a better alternative I'm all ears but having /proc and
> > > ifconfig return zeros for error counts
On Sat, 28 Nov 2020 01:21:40 +0200 Vladimir Oltean wrote:
> On Fri, Nov 27, 2020 at 01:37:53PM -0800, Jakub Kicinski wrote:
> > High speed systems are often eventually consistent. Either because
> > stats are gathered from HW periodically by the FW, or RCU grace period
> > has to expire, or workque
On Sat, Nov 28, 2020 at 12:30:48AM +0100, Andrew Lunn wrote:
> > If there is a better alternative I'm all ears but having /proc and
> > ifconfig return zeros for error counts while ip link doesn't will lead
> > to too much confusion IMO. While delayed update of stats is a fact of
> > life for _year
On Fri, Nov 27, 2020 at 01:37:53PM -0800, Jakub Kicinski wrote:
> High speed systems are often eventually consistent. Either because
> stats are gathered from HW periodically by the FW, or RCU grace period
> has to expire, or workqueue has to run, etc. etc. I know it's annoying
> for writing tests
On Fri, Nov 27, 2020 at 02:14:02PM -0800, Jakub Kicinski wrote:
> On Fri, 27 Nov 2020 22:32:44 +0100 Andrew Lunn wrote:
> > > > So long as these counters are still in ethtool -S, i guess it does not
> > > > matter. That i do trust to be accurate, and probably consistent across
> > > > the counters
On Fri, Nov 27, 2020 at 01:37:53PM -0800, Jakub Kicinski wrote:
> Replying to George's email 'cause I didn't get Vladimir's email from
> the ML.
>
> On Fri, 27 Nov 2020 14:58:29 -0600 George McCollister wrote:
> > > 100 Kbps = 12.5KB/s.
> > > sja1105 has 93 64-bit counters, and during every counter
> Either way, can we conclude that ndo_get_stats64 is not a replacement
> for ethtool -S, since the latter is blocking and, if implemented correctly,
> can return the counters at the time of the call (therefore making sure
> that anything that happened before the syscall has been accounted into
> t
On Fri, 27 Nov 2020 22:32:44 +0100 Andrew Lunn wrote:
> > > So long as these counters are still in ethtool -S, i guess it does not
> > > matter. That i do trust to be accurate, and probably consistent across
> > > the counters it returns.
> >
> > Not in the NIC designs I'm familiar with.
>
>
On Fri, 27 Nov 2020 23:23:42 +0200 Vladimir Oltean wrote:
> On Fri, Nov 27, 2020 at 01:13:46PM -0800, Jakub Kicinski wrote:
> > On Fri, 27 Nov 2020 21:47:14 +0100 Andrew Lunn wrote:
> > > > Is the periodic refresh really that awful? We're mostly talking error
> > > > counters here so every second
Replying to George's email 'cause I didn't get Vladimir's email from
the ML.
On Fri, 27 Nov 2020 14:58:29 -0600 George McCollister wrote:
> > 100 Kbps = 12.5KB/s.
> > sja1105 has 93 64-bit counters, and during every counter refresh cycle I
Are these 93 for one port? That sounds like a lot.. The
> > So long as these counters are still in ethtool -S, i guess it does not
> > matter. That i do trust to be accurate, and probably consistent across
> > the counters it returns.
>
> Not in the NIC designs I'm familiar with.
Many NICs have a way to take a hardware snapshot of all counters. You
ca
On Fri, Nov 27, 2020 at 01:13:46PM -0800, Jakub Kicinski wrote:
> On Fri, 27 Nov 2020 21:47:14 +0100 Andrew Lunn wrote:
> > > Is the periodic refresh really that awful? We're mostly talking error
> > > counters here so every second or every few seconds should be perfectly
> > > fine.
> >
> > Humm,
On Fri, 27 Nov 2020 21:47:14 +0100 Andrew Lunn wrote:
> > Is the periodic refresh really that awful? We're mostly talking error
> > counters here so every second or every few seconds should be perfectly
> > fine.
>
> Humm, i would prefer error counts to be more correct than anything
> else. When
On Fri, Nov 27, 2020 at 1:50 PM Vladimir Oltean wrote:
>
> On Fri, Nov 27, 2020 at 12:47:41PM -0600, George McCollister wrote:
> > On Fri, Nov 27, 2020, 12:35 PM Jakub Kicinski wrote:
> >
> > > On Fri, 27 Nov 2020 00:05:00 +0200 Vladimir Oltean wrote:
> > > > On Thu, Nov 26, 2020 at 01:07:12PM -0
> Is the periodic refresh really that awful? We're mostly talking error
> counters here so every second or every few seconds should be perfectly
> fine.
Humm, i would prefer error counts to be more correct than anything
else. When debugging issues, you generally don't care how many packets
worked.
On Fri, Nov 27, 2020 at 12:47:41PM -0600, George McCollister wrote:
> On Fri, Nov 27, 2020, 12:35 PM Jakub Kicinski wrote:
>
> > On Fri, 27 Nov 2020 00:05:00 +0200 Vladimir Oltean wrote:
> > > On Thu, Nov 26, 2020 at 01:07:12PM -0600, George McCollister wrote:
> > > > On Thu, Nov 26, 2020 at 11:5
On Fri, 27 Nov 2020 00:05:00 +0200 Vladimir Oltean wrote:
> On Thu, Nov 26, 2020 at 01:07:12PM -0600, George McCollister wrote:
> > On Thu, Nov 26, 2020 at 11:56 AM Vladimir Oltean wrote:
> >
> > > On Thu, Nov 26, 2020 at 03:24:18PM +0200, Vladimir Oltean wrote:
> > > > On Wed, Nov 25, 2020 a
On Thu, Nov 26, 2020 at 01:07:12PM -0600, George McCollister wrote:
> On Thu, Nov 26, 2020 at 11:56 AM Vladimir Oltean wrote:
> >
> > On Thu, Nov 26, 2020 at 03:24:18PM +0200, Vladimir Oltean wrote:
> > > On Wed, Nov 25, 2020 at 08:25:11PM -0600, George McCollister wrote:
> > > > > > + {XRS_RX
On Thu, Nov 26, 2020 at 11:56 AM Vladimir Oltean wrote:
>
> On Thu, Nov 26, 2020 at 03:24:18PM +0200, Vladimir Oltean wrote:
> > On Wed, Nov 25, 2020 at 08:25:11PM -0600, George McCollister wrote:
> > > > > + {XRS_RX_UNDERSIZE_L, "rx_undersize"},
> > > > > + {XRS_RX_FRAGMENTS_L, "rx_fragme
On Thu, Nov 26, 2020 at 03:24:18PM +0200, Vladimir Oltean wrote:
> On Wed, Nov 25, 2020 at 08:25:11PM -0600, George McCollister wrote:
> > > > + {XRS_RX_UNDERSIZE_L, "rx_undersize"},
> > > > + {XRS_RX_FRAGMENTS_L, "rx_fragments"},
> > > > + {XRS_RX_OVERSIZE_L, "rx_oversize"},
> > > > +
On Wed, Nov 25, 2020 at 08:25:11PM -0600, George McCollister wrote:
> > > + {XRS_RX_UNDERSIZE_L, "rx_undersize"},
> > > + {XRS_RX_FRAGMENTS_L, "rx_fragments"},
> > > + {XRS_RX_OVERSIZE_L, "rx_oversize"},
> > > + {XRS_RX_JABBER_L, "rx_jabber"},
> > > + {XRS_RX_ERR_L, "rx_err"},
>
On Wed, Nov 25, 2020 at 7:42 PM Jakub Kicinski wrote:
>
> On Wed, 25 Nov 2020 13:37:39 -0600 George McCollister wrote:
> > Add a driver with initial support for the Arrow SpeedChips XRS7000
> > series of gigabit Ethernet switch chips which are typically used in
> > critical networking applications
On Wed, 25 Nov 2020 13:37:39 -0600 George McCollister wrote:
> Add a driver with initial support for the Arrow SpeedChips XRS7000
> series of gigabit Ethernet switch chips which are typically used in
> critical networking applications.
>
> The switches have up to three RGMII ports and one RMII por
Add a driver with initial support for the Arrow SpeedChips XRS7000
series of gigabit Ethernet switch chips which are typically used in
critical networking applications.
The switches have up to three RGMII ports and one RMII port.
Management to the switches can be performed over i2c or mdio.
Suppo
36 matches
Mail list logo
