Skip to contentSkip to conversation

sunvnet: add jumbo frames support

PATCH Superseded David L Stevens 2 participants 2 messages Sep 17, 2014

Subsystems (2)

v5 of 9 Superseded Latest is v9 →

lore
Share & tools
lore
#0 lore raw

v5 cover sunvnet: add jumbo frames support

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 <[email protected]>
- added cookies to support non-contiguous buffers of max size
Changes from v3:
- added version functions per Dave Miller <[email protected]>
- moved rmtu to vnet_port per Dave Miller <[email protected]>
- explicitly set options bits and capability flags to 0 per Raghuram Kothakota <[email protected]>
Changes from v2:
- make checkpatch clean
Changes from v1:
- fix brace formatting per Dave Miller <[email protected]>

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(-)
#1 lore raw
Quoted 8 lines
 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