[PATCHv5 net-next 0/3] sunvnet: add jumbo frames support

[PATCHv5 net-next 0/3] sunvnet: add jumbo frames support

[David L Stevens]

This patch set updates the sunvnet driver to version 1.6 of the VIO protocol
to support per-port exchange of MTU information and allow non-standard MTU
sizes, including jumbo frames.

Using large MTUs shows a > 4X throughput improvement Linux-Solaris
and > 8X throughput improvement Linux-Linux.

Changes from v4:
	- changed VNET_MAXPACKET per David Laight <David.Laight@ACULAB.COM>
	- added cookies to support non-contiguous buffers of max size
Changes from v3:
	- added version functions per Dave Miller <davem@davemloft.net>
	- moved rmtu to vnet_port per Dave Miller <davem@davemloft.net>
	- explicitly set options bits and capability flags to 0 per
		Raghuram Kothakota <Raghuram.Kothakota@oracle.com>
Changes from v2:
	- make checkpatch clean
Changes from v1:
	- fix brace formatting per Dave Miller <davem@davemloft.net>

David L Stevens (3):
  sunvnet: upgrade to VIO protocol version 1.6
  sunvnet: allow admin to set sunvnet MTU
  sunvnet: generate ICMP PTMUD messages for smaller port MTUs

 arch/sparc/include/asm/vio.h       |   44 ++++++++++-
 arch/sparc/kernel/ldc.c            |    2 +-
 arch/sparc/kernel/viohs.c          |   14 +++-
 drivers/net/ethernet/sun/sunvnet.c |  146 +++++++++++++++++++++++++++++++-----
 drivers/net/ethernet/sun/sunvnet.h |    7 ++-
 5 files changed, 187 insertions(+), 26 deletions(-)

Re: [PATCHv5 net-next 0/3] sunvnet: add jumbo frames support

[Sowmini Varadhan]

> 
>  arch/sparc/include/asm/vio.h       |   44 ++++++++++-
>  arch/sparc/kernel/ldc.c            |    2 +-
>  arch/sparc/kernel/viohs.c          |   14 +++-
>  drivers/net/ethernet/sun/sunvnet.c |  146 +++++++++++++++++++++++++++++++-----
>  drivers/net/ethernet/sun/sunvnet.h |    7 ++-
>  5 files changed, 187 insertions(+), 26 deletions(-)
> 

A logistical question- this patch-set spans both sparc-next/sparclinux 
net-next/netdev, and there are obviously some dependancies here. 
What's the prescribed way to handle this sort of thing? 

(I ask, because I expect to soon be confronting a similar question with
some Rx side latency improvements that I'm working on, which will require
new functions for enabling/disabling interrupts in arch/sparc/kernel,
and I am wondering how that should get sequenced).

--Sowmini