[lkml]   [2015]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCHSET] printk, netconsole: implement reliable netconsole
From: Of Rob Landley
> Sent: 19 April 2015 08:25
> On Thu, Apr 16, 2015 at 6:03 PM, Tejun Heo <> wrote:
> > In a lot of configurations, netconsole is a useful way to collect
> > system logs; however, all netconsole does is simply emitting UDP
> > packets for the raw messages and there's no way for the receiver to
> > find out whether the packets were lost and/or reordered in flight.
> Except a modern nonsaturated LAN shouldn't do that.
> If you have two machines plugged into a hub, and that's _all_ that's
> plugged in, packets should never get dropped. This was the original
> use case of netconsole was that the sender and the receiver were
> plugged into the same router.
> However, even on a quite active LAN the days of ethernet doing CDMA
> requiring retransmits are long gone, even 100baseT routers have been
> cacheing and retransmitting data internally so each connection can go
> at the full 11 megabytes/second with the backplane running fast enough
> to keep them all active at the same time. (That's why it's so hard to
> find a _hub_ anymore, it's all routers

Most machines are plugged into switches (not routers), many of them
will send 'pause' frames which the host mac may act on.
In which case packet loss is not expected (unless you have broadcast storms
when all bets are off).

Additionally, within a local network you shouldn't really get any packet
loss since no segments should be 100% loaded.
So for testing it is not unreasonable to expect no lost packets in netconsole


 \ /
  Last update: 2015-04-20 14:21    [W:0.206 / U:1.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site