Re: [PATCH] sh_eth: fix TX buffer byte-swapping

[Rob Landley]

On Sun, Dec 13, 2015 at 12:27 PM, Sergei Shtylyov
 wrote:
> For the little-endian SH771x kernels the driver has to byte-swap the RX/TX
> buffers,  however yet unset physcial address from the TX descriptor is used
> to call sh_eth_soft_swap(). Use 'skb->data' instead...

Rummage rummage rummage...

Ah, my sh4 qemu system has an rtl-8139cp network driver, and the sh2
j-core numato board one is A) big endian, B) has an oddball version
with its own driver.

That's why I haven't hit this.

Rob
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHSET] printk, netconsole: implement reliable netconsole

[Rob Landley]

On Thu, Apr 16, 2015 at 6:03 PM, Tejun Heo t...@kernel.org 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. The point of routers is they
cache internally and send the packet only out the connection they
should go, based on an internal routing table because they listened to
incoming packets to figure out who lives where and do arp-like
things.)

And of course gigabit is a point to point protocol that has nothing to
do with conventional ethernet at _all_ other than the name, as far as
I know it can't _not_ do this.

So are you trying to program around a problem you've actually _seen_,
or are you attempting to reinvent TCP/IP yet again based on top of UDP
(Drink!) because of a purely theoretical issue?

Or are you trying to route netconsole, unencapsulated, across the
internet? Of course the internet itself refusing to drop packets but
instead buffering and retransmitting them even when doing so turns out
to be a really bad idea is sort of where this whole bufferbloat
thing came from. So again, even in that context, is this a problem
you've actually _seen_?

 printk already keeps log metadata which contains enough information to
 make netconsole reliable.  This patchset does the followings.

Adds a giant amount of complexity without quite explaining why.

Rob
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html