So I think the vr(4) diff has had a reasonable amount of testing;
any objections or ideally OKs to commit it?
I have also tested sis(4) on a PC Engines WRAP now; despite the
DP83815 datasheet indicating that Accept Long Packets
(SIS_RXCFG_RX_JABBER) should permit frames up to 2046 it seems
something more is required for that; however setting mtu to 1518
does work. In the case of sis(4) there is no change to how the chip
is programmed at all, so this is a NOOP unless somebody deliberately
configures a larger MTU on the device. Therefore I believe that
this would be safe to allow without a big round of testing. OK?
Both diffs below.
(totally unrelated but I was interested to note that the source
code for the BIOS used on the WRAP is available for download).
Index: if_vr.c
===
RCS file: /cvs/src/sys/dev/pci/if_vr.c,v
retrieving revision 1.126
diff -u -p -r1.126 if_vr.c
--- if_vr.c 28 Jan 2013 02:57:02 - 1.126
+++ if_vr.c 9 Feb 2013 15:24:48 -
@@ -164,6 +164,7 @@ int vr_alloc_mbuf(struct vr_softc *, str
#defineVR_Q_CAM(12)
#defineVR_Q_HWTAG (13)
#defineVR_Q_INTDISABLE (14)
+#defineVR_Q_BABYJUMBO (15) /* others may work too */
struct vr_type {
pci_vendor_id_t vr_vid;
@@ -175,11 +176,12 @@ struct vr_type {
{ PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_RHINEII,
VR_Q_NEEDALIGN },
{ PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_RHINEII_2,
- 0 },
+ VR_Q_BABYJUMBO },
{ PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_VT6105,
- 0 },
+ VR_Q_BABYJUMBO },
{ PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_VT6105M,
- VR_Q_CSUM | VR_Q_CAM | VR_Q_HWTAG | VR_Q_INTDISABLE },
+ VR_Q_CSUM | VR_Q_CAM | VR_Q_HWTAG | VR_Q_INTDISABLE |
+ VR_Q_BABYJUMBO },
{ PCI_VENDOR_DELTA, PCI_PRODUCT_DELTA_RHINEII,
VR_Q_NEEDALIGN },
{ PCI_VENDOR_ADDTRON, PCI_PRODUCT_ADDTRON_RHINEII,
@@ -630,6 +632,9 @@ vr_attach(struct device *parent, struct
ifp-if_ioctl = vr_ioctl;
ifp-if_start = vr_start;
ifp-if_watchdog = vr_watchdog;
+ if (sc-vr_quirks VR_Q_BABYJUMBO)
+ ifp-if_hardmtu = VR_RXLEN_BABYJUMBO -
+ ETHER_HDR_LEN - ETHER_CRC_LEN;
IFQ_SET_READY(ifp-if_snd);
bcopy(sc-sc_dev.dv_xname, ifp-if_xname, IFNAMSIZ);
@@ -1745,7 +1750,10 @@ vr_alloc_mbuf(struct vr_softc *sc, struc
r-vr_mbuf = m;
d = r-vr_ptr;
d-vr_data = htole32(r-vr_map-dm_segs[0].ds_addr);
- d-vr_ctl = htole32(VR_RXCTL | VR_RXLEN);
+ if (sc-vr_quirks VR_Q_BABYJUMBO)
+ d-vr_ctl = htole32(VR_RXCTL | VR_RXLEN_BABYJUMBO);
+ else
+ d-vr_ctl = htole32(VR_RXCTL | VR_RXLEN);
bus_dmamap_sync(sc-sc_dmat, sc-sc_listmap.vrm_map, 0,
sc-sc_listmap.vrm_map-dm_mapsize, BUS_DMASYNC_PREWRITE);
Index: if_vrreg.h
===
RCS file: /cvs/src/sys/dev/pci/if_vrreg.h,v
retrieving revision 1.34
diff -u -p -r1.34 if_vrreg.h
--- if_vrreg.h 28 Jan 2013 02:57:02 - 1.34
+++ if_vrreg.h 9 Feb 2013 15:24:48 -
@@ -437,6 +437,8 @@ struct vr_desc {
#define VR_TX_LIST_CNT 128
#define VR_MIN_FRAMELEN60
#define VR_RXLEN 1524
+/* determined experimentally; seems intermittent with higher values */
+#define VR_RXLEN_BABYJUMBO 1758
#define VR_TX_INTR_THRESH 8
struct vr_list_data {
Index: if_sis.c
===
RCS file: /cvs/src/sys/dev/pci/if_sis.c,v
retrieving revision 1.107
diff -u -p -r1.107 if_sis.c
--- if_sis.c29 Nov 2012 21:10:32 - 1.107
+++ if_sis.c9 Feb 2013 15:21:16 -
@@ -1093,6 +1093,7 @@ sis_attach(struct device *parent, struct
IFQ_SET_MAXLEN(ifp-if_snd, SIS_TX_LIST_CNT - 1);
IFQ_SET_READY(ifp-if_snd);
bcopy(sc-sc_dev.dv_xname, ifp-if_xname, IFNAMSIZ);
+ ifp-if_hardmtu = 1518; /* determined experimentally on DP83815 */
ifp-if_capabilities = IFCAP_VLAN_MTU;
On 2013/02/07 17:41, Stuart Henderson wrote:
At least the following vr(4) devices can be configured to permit
larger MTUs.
vr0 at pci0 dev 18 function 0 VIA RhineII-2 rev 0x51: irq 11, address
00:40:63:c0:5d:27
vr1 at pci2 dev 0 function 0 VIA VT6105M RhineIII rev 0x96: irq 5, address
00:00:24:cd:72:30
This is extremely useful as it permits carrying stacked vlans
on Alix/net5501, and also permits carrying 1500 MTU packets within
pppoe(4) using the RFC4638 support.
As seems to be common for fast ethernet chips, the register to set
the length is 11 bits. When tested, both these NICs performed
stably with an MTU of 1748 (around 95Mb/s throughput on my test
machine, dmesg below); with a slightly higher MTU things mostly
still
