From pa4dan@Vitsch.net  Sat Apr 16 11:09:10 2005
Return-Path: <pa4dan@Vitsch.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 59D9C16A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 16 Apr 2005 11:09:10 +0000 (GMT)
Received: from amsfep15-int.chello.nl (nl-ams-slo-l4-01-pip-8.chellonetwork.com [213.46.243.27])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5F3EA43D1D
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 16 Apr 2005 11:09:08 +0000 (GMT)
	(envelope-from pa4dan@Vitsch.net)
Received: from Vitsch.net ([62.195.39.211]) by amsfep15-int.chello.nl
          (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP
          id <20050416110906.XWDI3629.amsfep15-int.chello.nl@Vitsch.net>
          for <FreeBSD-gnats-submit@freebsd.org>;
          Sat, 16 Apr 2005 13:09:06 +0200
Received: (from pa4dan@localhost)
	by Vitsch.net (8.12.3p2/8.11.3) id j3GB8GGi088443;
	Sat, 16 Apr 2005 13:08:16 +0200 (CEST)
	(envelope-from pa4dan)
Message-Id: <200504161108.j3GB8GGi088443@Vitsch.net>
Date: Sat, 16 Apr 2005 13:08:16 +0200 (CEST)
From: "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net>
Reply-To: "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [PATCH] Give sk(4) VLAN MTU capabilities
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         79998
>Category:       kern
>Synopsis:       [sk] [patch] Give sk(4) VLAN MTU capabilities
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    yar
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Apr 16 11:10:25 GMT 2005
>Closed-Date:    Fri Dec 30 20:16:34 GMT 2005
>Last-Modified:  Fri Dec 30 20:16:34 GMT 2005
>Originator:     Daan Vreeken [PA4DAN]
>Release:        FreeBSD 5.3-RELEASE i386
>Organization:
Vitsch Electronics
>Environment:
System: FreeBSD Racebeest.Danovitsch.LAN 5.3-RELEASE FreeBSD 5.3-RELEASE #8: Tue Mar 15 20:52:24 CET 2005 root@Racebeest.Danovitsch.LAN:/usr/src.5.3-release/sys/i386/compile/Laptop i386


	
>Description:
	Although sk(4) adapters can handle an MTU of up to 9000, the driver
	doesn't set the IFCAP_VLAN_MTU bit in it's capabilities.
>How-To-Repeat:
	n/a
>Fix:

	Apply the following patch to -current. It sets the IFCAP_VLAN_MTU
	bit and updates the vlan(4) manual page.

--- 2005-04-16_sk_vlan.diff begins here ---
--- sys/pci/if_sk.c.current	Thu Apr 14 11:28:45 2005
+++ sys/pci/if_sk.c	Sat Apr 16 12:23:19 2005
@@ -1449,6 +1449,8 @@
 	ifp->if_watchdog = sk_watchdog;
 	ifp->if_init = sk_init;
 	ifp->if_baudrate = 1000000000;
+	ifp->if_capabilities = IFCAP_VLAN_MTU;
+	ifp->if_capenable = ifp->if_capabilities;
 	IFQ_SET_MAXLEN(&ifp->if_snd, SK_TX_RING_CNT - 1);
 	ifp->if_snd.ifq_drv_maxlen = SK_TX_RING_CNT - 1;
 	IFQ_SET_READY(&ifp->if_snd);
--- share/man/man4/vlan.4.current	Sat Apr 16 12:35:11 2005
+++ share/man/man4/vlan.4	Sat Apr 16 12:36:29 2005
@@ -151,6 +151,10 @@
 supports long frames for
 .Nm
 natively.
+.It Xr sk 4
+supports long frames for
+.Nm
+natively.
 .It Xr ste 4
 supports long frames for
 .Nm
--- 2005-04-16_sk_vlan.diff ends here ---


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->bz 
Responsible-Changed-By: bz 
Responsible-Changed-When: Sat Apr 16 11:39:12 GMT 2005 
Responsible-Changed-Why:  
I'll handle this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=79998 

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: bug-followup@FreeBSD.org, Danovitsch@Vitsch.net, bz@FreeBSD.org
Cc:  
Subject: Re: kern/79998: [if_sk] [patch] Give sk(4) VLAN MTU capabilities
Date: Mon, 3 Oct 2005 06:59:51 +0400

 Folks,
 
 Just came across this PR and now wondering if all the sk(4) NICs
 can receive 9k-byte frames in the default mode of operation.  If
 they can, the patch may be committed as is.  However, there might
 be some bits to set and knobs to frob in the chip...  I've never
 seen an sk(4), but, e.g., fxp(4) won't pass large frames to the
 host until some chip-dependent magic has been cast.
 
 -- 
 Yar

From: "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net>
To: Yar Tikhiy <yar@comp.chem.msu.su>, Bug-followup@FreeBSD.org,
   bz@FreeBSD.org
Cc:  
Subject: Re: kern/79998: [if_sk] [patch] Give sk(4) VLAN MTU capabilities
Date: Wed, 5 Oct 2005 11:23:44 +0200

 On Monday 03 October 2005 04:59, you wrote:
 > Folks,
 >
 > Just came across this PR and now wondering if all the sk(4) NICs
 > can receive 9k-byte frames in the default mode of operation.  If
 > they can, the patch may be committed as is.  However, there might
 > be some bits to set and knobs to frob in the chip...  I've never
 > seen an sk(4), but, e.g., fxp(4) won't pass large frames to the
 > host until some chip-dependent magic has been cast.
 
 The sk driver "frobs the knobs" when a big MTU is selected. This snippet from 
 sk_init_xmac() is where the magic happens :
 
   if (ifp->if_mtu > (ETHERMTU + ETHER_HDR_LEN + ETHER_CRC_LEN))
           SK_XM_SETBIT_2(sc_if, XM_RXCMD, XM_RXCMD_BIGPKTOK);
   else
           SK_XM_CLRBIT_2(sc_if, XM_RXCMD, XM_RXCMD_BIGPKTOK);
 
 I can only test on the two SK cards that I have here, but on the cards that I 
 have Jumbo-frames seem to work. I couldn't find anything in the driver or the 
 manual about certain cards not working with Jumbo frames, so I would say the 
 SK driver is simply missing the "VLAN capable" flag.
 
 By the way, this is the dmesg output of one of the SK cards I have here :
 skc0: <Marvell Gigabit Ethernet> port 0xd000-0xd0ff mem 0xea000000-0xea003fff 
 irq 12 at device 7.0 on pci1
 skc0: interrupt moderation is 100 us
 skc0: Marvell Yukon Gigabit Ethernet rev. (0x1)
 sk0: <Marvell Semiconductor, Inc. Yukon> on skc0
 sk0: Ethernet address: 00:04:e2:da:3f:96
 miibus1: <MII bus> on sk0
 skc0: interrupt moderation is 500 us
 sk0: promiscuous mode enabled
 
 --
 Daan

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net>
Cc: Bug-followup@FreeBSD.org, bz@FreeBSD.org
Subject: Re: kern/79998: [if_sk] [patch] Give sk(4) VLAN MTU capabilities
Date: Wed, 5 Oct 2005 14:10:32 +0400

 On Wed, Oct 05, 2005 at 11:23:44AM +0200, Daan Vreeken [PA4DAN] wrote:
 > On Monday 03 October 2005 04:59, you wrote:
 > > Folks,
 > >
 > > Just came across this PR and now wondering if all the sk(4) NICs
 > > can receive 9k-byte frames in the default mode of operation.  If
 > > they can, the patch may be committed as is.  However, there might
 > > be some bits to set and knobs to frob in the chip...  I've never
 > > seen an sk(4), but, e.g., fxp(4) won't pass large frames to the
 > > host until some chip-dependent magic has been cast.
 > 
 > The sk driver "frobs the knobs" when a big MTU is selected. This snippet from 
 > sk_init_xmac() is where the magic happens :
 > 
 >   if (ifp->if_mtu > (ETHERMTU + ETHER_HDR_LEN + ETHER_CRC_LEN))
 >           SK_XM_SETBIT_2(sc_if, XM_RXCMD, XM_RXCMD_BIGPKTOK);
 >   else
 >           SK_XM_CLRBIT_2(sc_if, XM_RXCMD, XM_RXCMD_BIGPKTOK);
 > 
 > I can only test on the two SK cards that I have here, but on the cards that I 
 > have Jumbo-frames seem to work. I couldn't find anything in the driver or the 
 > manual about certain cards not working with Jumbo frames, so I would say the 
 > SK driver is simply missing the "VLAN capable" flag.
 
 If the ability to receive big packets is toggled in sk by the commads
 you displayed, sk will become "VLAN MTU capable" as soon as code
 is added to its driver to turn on the ability in responce to setting
 IFCAP_VLANMTU in the if_capenable field.  I'd suggest adding a
 reference counter to softc indicating the current setting of
 XM_RXCMD_BIGPKTOK (> 0 means on, 0 means off).  The reference
 counter, not just a flag, is needed to allow for several consumers
 of XM_RXCMD_BIGPKTOK in the driver.  Then the hardware feature could
 be enabled at more than one place in the driver, e.g., in responce
 to big MTU setting as well as to IFCAP_VLANMTU setting.  This should
 be rather easy.  I think I can help you with the patch.
 
 -- 
 Yar

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net>
Cc: Bug-followup@FreeBSD.org, bz@FreeBSD.org
Subject: Re: kern/79998: [if_sk] [patch] Give sk(4) VLAN MTU capabilities
Date: Sun, 9 Oct 2005 15:26:31 +0400

 On Wed, Oct 05, 2005 at 11:23:44AM +0200, Daan Vreeken [PA4DAN] wrote:
 > On Monday 03 October 2005 04:59, you wrote:
 > >
 > > Just came across this PR and now wondering if all the sk(4) NICs
 > > can receive 9k-byte frames in the default mode of operation.  If
 > > they can, the patch may be committed as is.  However, there might
 > > be some bits to set and knobs to frob in the chip...  I've never
 > > seen an sk(4), but, e.g., fxp(4) won't pass large frames to the
 > > host until some chip-dependent magic has been cast.
 > 
 > The sk driver "frobs the knobs" when a big MTU is selected. This snippet from 
 > sk_init_xmac() is where the magic happens :
 > 
 >   if (ifp->if_mtu > (ETHERMTU + ETHER_HDR_LEN + ETHER_CRC_LEN))
 >           SK_XM_SETBIT_2(sc_if, XM_RXCMD, XM_RXCMD_BIGPKTOK);
 >   else
 >           SK_XM_CLRBIT_2(sc_if, XM_RXCMD, XM_RXCMD_BIGPKTOK);
 > 
 > I can only test on the two SK cards that I have here, but on the cards that I 
 > have Jumbo-frames seem to work. I couldn't find anything in the driver or the 
 > manual about certain cards not working with Jumbo frames, so I would say the 
 > SK driver is simply missing the "VLAN capable" flag.
 
 Daan, could you please test with your sk cards whether they can
 hadle big VLAN packets _without_ setting a jumbo MTU, i.e., with
 their MTU left at 1500 bytes?  I read some pieces of the sk driver
 source code and got an impression that both XMAC and Yukon cards
 should be able to handle big VLAN packets (up to 1518 octets at
 least) in the default mode of operation.  To perform the testing,
 just make sure that MTU on both sk and vlan interfaces is 1500 bytes
 and ping one machine from the other through the vlan with packets
 of maximum size:
 ping -s 1472 ...
 
 If my conclusion is true, your patch can be applied as is, without
 any other modifications to the sk driver, and I can commit it.
 
 -- 
 Yar

From: "Bjoern A. Zeeb" <bz@FreeBSD.org>
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net>,
	Bug-followup@FreeBSD.org
Subject: Re: kern/79998: [if_sk] [patch] Give sk(4) VLAN MTU capabilities
Date: Sun, 9 Oct 2005 16:06:21 +0000 (UTC)

 On Sun, 9 Oct 2005, Yar Tikhiy wrote:
 
 > > I can only test on the two SK cards that I have here, but on the cards that I
 > > have Jumbo-frames seem to work. I couldn't find anything in the driver or the
 > > manual about certain cards not working with Jumbo frames, so I would say the
 > > SK driver is simply missing the "VLAN capable" flag.
 
 it's not really a problem of jumbograms.
 
 > Daan, could you please test with your sk cards whether they can
 > hadle big VLAN packets _without_ setting a jumbo MTU, i.e., with
 > their MTU left at 1500 bytes?  I read some pieces of the sk driver
 > source code and got an impression that both XMAC and Yukon cards
 > should be able to handle big VLAN packets (up to 1518 octets at
 > least) in the default mode of operation.  To perform the testing,
 > just make sure that MTU on both sk and vlan interfaces is 1500 bytes
 > and ping one machine from the other through the vlan with packets
 > of maximum size:
 > ping -s 1472 ...
 >
 > If my conclusion is true, your patch can be applied as is, without
 > any other modifications to the sk driver, and I can commit it.
 
 I am unsure for the Genesis/XMACii one.
 If you have the time to work on this you can find some documentation
 in the datasheet on http://people.freebsd.org/~wpaul/SysKonnect/ .
 
 Feel free to grab the PR then.
 
 -- 
 Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
State-Changed-From-To: open->analyzed 
State-Changed-By: yar 
State-Changed-When: Sun Oct 9 16:53:25 GMT 2005 
State-Changed-Why:  
The cards seem to actually have the functionality needed. 


Responsible-Changed-From-To: bz->yar 
Responsible-Changed-By: yar 
Responsible-Changed-When: Sun Oct 9 16:53:25 GMT 2005 
Responsible-Changed-Why:  
Hoping to solve this VLAN-related issue. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=79998 

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: "Bjoern A. Zeeb" <bz@FreeBSD.org>
Cc: "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net>, Bug-followup@FreeBSD.org
Subject: Re: kern/79998: [if_sk] [patch] Give sk(4) VLAN MTU capabilities
Date: Sun, 9 Oct 2005 20:52:37 +0400

 On Sun, Oct 09, 2005 at 04:06:21PM +0000, Bjoern A. Zeeb wrote:
 > On Sun, 9 Oct 2005, Yar Tikhiy wrote:
 > 
 > > > I can only test on the two SK cards that I have here, but on the cards that I
 > > > have Jumbo-frames seem to work. I couldn't find anything in the driver or the
 > > > manual about certain cards not working with Jumbo frames, so I would say the
 > > > SK driver is simply missing the "VLAN capable" flag.
 > 
 > it's not really a problem of jumbograms.
 
 Agreed, SK cards have different knobs for VLAN frames, and
 they seem to be on in the default mode of our sk(4) driver.
 
 > I am unsure for the Genesis/XMACii one.
 > If you have the time to work on this you can find some documentation
 > in the datasheet on http://people.freebsd.org/~wpaul/SysKonnect/ .
 
 Already peeked in the doco.  XMAC II has a register called VLAN
 Level 1.  The register can be set to ethertype of VLAN-tagged frames.
 The NIC is a smart-ass, it recieves a big (>1514 bytes) frame to
 its buffer and then decides whether it is OK to pass the big frame
 to the host under the current conditions.  One of OK cases is when
 the frame ethertype matches the value in the register.  And it is
 0x8100 by default, which is exactly the 802.1q ethertype.
 
 > Feel free to grab the PR then.
 
 OK, taking it.
 
 -- 
 Yar

From: "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net>
To: Yar Tikhiy <yar@comp.chem.msu.su>, Bug-followup@FreeBSD.org,
   bz@FreeBSD.org
Cc:  
Subject: Re: kern/79998: [if_sk] [patch] Give sk(4) VLAN MTU capabilities
Date: Tue, 11 Oct 2005 11:39:12 +0200

 On Sunday 09 October 2005 13:26, you wrote:
 > On Wed, Oct 05, 2005 at 11:23:44AM +0200, Daan Vreeken [PA4DAN] wrote:
 > > On Monday 03 October 2005 04:59, you wrote:
 > > > Just came across this PR and now wondering if all the sk(4) NICs
 > > > can receive 9k-byte frames in the default mode of operation.  If
 > > > they can, the patch may be committed as is.  However, there might
 > > > be some bits to set and knobs to frob in the chip...  I've never
 > > > seen an sk(4), but, e.g., fxp(4) won't pass large frames to the
 > > > host until some chip-dependent magic has been cast.
 > >
 > > The sk driver "frobs the knobs" when a big MTU is selected. This snippet
 > > from sk_init_xmac() is where the magic happens :
 > >
 > >   if (ifp->if_mtu > (ETHERMTU + ETHER_HDR_LEN + ETHER_CRC_LEN))
 > >           SK_XM_SETBIT_2(sc_if, XM_RXCMD, XM_RXCMD_BIGPKTOK);
 > >   else
 > >           SK_XM_CLRBIT_2(sc_if, XM_RXCMD, XM_RXCMD_BIGPKTOK);
 > >
 > > I can only test on the two SK cards that I have here, but on the cards
 > > that I have Jumbo-frames seem to work. I couldn't find anything in the
 > > driver or the manual about certain cards not working with Jumbo frames,
 > > so I would say the SK driver is simply missing the "VLAN capable" flag.
 >
 > Daan, could you please test with your sk cards whether they can
 > hadle big VLAN packets _without_ setting a jumbo MTU, i.e., with
 > their MTU left at 1500 bytes?  I read some pieces of the sk driver
 > source code and got an impression that both XMAC and Yukon cards
 > should be able to handle big VLAN packets (up to 1518 octets at
 > least) in the default mode of operation.  To perform the testing,
 > just make sure that MTU on both sk and vlan interfaces is 1500 bytes
 > and ping one machine from the other through the vlan with packets
 > of maximum size:
 > ping -s 1472 ...
 >
 > If my conclusion is true, your patch can be applied as is, without
 > any other modifications to the sk driver, and I can commit it.
 
 With the patch applied I have tested it on two systems running FreeBSD with 
 two Yukon cards with the following commands :
 
 ifconfig vlan0 create
 ifconfig vlan0 vlan 3 vlandev sk0
 ifconfig vlan0 10.0.0.1
 ping 10.0.0.2
 
 (The other machine being 10.0.0.2)
 
 The sk0 interface and the vlan0 interface both show an MTU of 1500. I get ping 
 responses in both ways. A packet dump on sk0 shows 1518-byte packets going in 
 and out and a packet dump on vlan0 shows 1514-byte packets.
 As far as I can tell everything works as expected :)
 
 --
 Daan
State-Changed-From-To: analyzed->patched 
State-Changed-By: yar 
State-Changed-When: Wed Oct 12 08:50:35 GMT 2005 
State-Changed-Why:  
I've committed the change to CURRENT. 
Now let it stay there for a month to have a chance to catch 
possible problems with other flavors of sk(4) hardware before 
the change gets merged to 6-STABLE.  Thanks! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=79998 
State-Changed-From-To: patched->closed 
State-Changed-By: bz 
State-Changed-When: Fri Dec 30 20:14:36 UTC 2005 
State-Changed-Why:  
Changes MFCed to RELENG_6: 
rev. 1.111 date: 2005/10/11 22:55:16; author: yar  sys/pci/if_sk.c 
rev. 1.28  date: 2005/10/11 22:59:01; author: yar  share/man/man4/vlan.4 
Thanks for submitting. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=79998 
>Unformatted:
