In the usual place:
ftp://ftp.kernel.org/pub/linux/kernel/people/davem/TIGON3/tg3-0.92.patch.gz
Three changes of note:
[FEATURE] Yay, real HW acceleration hooks in the 802.1q VLAN layer.
Tigon3 takes advantage of it.
[BUG FIX] Let tg3_read_partno fail, some boards do not provide the
information and it isn't critical to the operation of the
driver.
[BUG FIX] Minor bug in ETHTOOL_GREGS length handling.
[CLEANUP] Use netif_carrier_{ok,on,off}() to keep track of link state.
If people with real VLANs can try to get the HW acceleration stuff
working, I'd really appreciate it. Especially the person who (GASP)
wanted us to put the tasteless NICE stuff into our driver. :-)
Adding support to the Acenic driver should be pretty easy and I'll
try to do that before catching some sleep. Jeff could also probably
cook up something quick for the e1000.
As previously mentioned, I'm mainly interested in "works/doesn't work"
reports at this point. And please accompany the:
eth1: Tigon3 [partno(BCM95700A6) rev 7102 PHY(5401)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:04:76:2f:e2:d0
kernel log message with your failure/success reports (and any other
interesting messages our driver prints out :-).
The current goal is to be feature complete and have no probe failures
or known bugs in basic operation by 0.95, then fine tuning and
performance work will be done from 0.96 till 1.0 Sometime after 0.95
occurs I will push the driver to Marcelo and Linus.
Thanks in advance for the testing.
"David S. Miller" wrote:
> If people with real VLANs can try to get the HW acceleration stuff
> working, I'd really appreciate it. Especially the person who (GASP)
> wanted us to put the tasteless NICE stuff into our driver. :-)
>
> Adding support to the Acenic driver should be pretty easy and I'll
> try to do that before catching some sleep. Jeff could also probably
> cook up something quick for the e1000.
I'll practice by adding to 8139cp driver first ;-)
e1000 has a VLAN filter type on-chip, which complicates things a tiny
bit.
I think dl2k gigabit driver has easy VLAN tagging, too. I'll try to
take care of that one was well (before tackling e1000 <g>)
Jeff
--
Jeff Garzik | "UNIX enhancements aren't."
Building 1024 | -- says /usr/games/fortune
MandrakeSoft |
On Wed, 27 Feb 2002, David S. Miller wrote:
>
> In the usual place:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/davem/TIGON3/tg3-0.92.patch.gz
>
> Three changes of note:
>
> [FEATURE] Yay, real HW acceleration hooks in the 802.1q VLAN layer.
> Tigon3 takes advantage of it.
> [BUG FIX] Let tg3_read_partno fail, some boards do not provide the
> information and it isn't critical to the operation of the
> driver.
> [BUG FIX] Minor bug in ETHTOOL_GREGS length handling.
> [CLEANUP] Use netif_carrier_{ok,on,off}() to keep track of link state.
>
> If people with real VLANs can try to get the HW acceleration stuff
> working, I'd really appreciate it. Especially the person who (GASP)
> wanted us to put the tasteless NICE stuff into our driver. :-)
>
Heh, I've never looked at the NICE-code.. I just found it working OK for
me :)
Anyway, I'm going to test this code after a while so I can be sure it
_should_ work (I have only one production system where I can test this so
I can't use very buggy drivers in it :)
> Adding support to the Acenic driver should be pretty easy and I'll
> try to do that before catching some sleep. Jeff could also probably
> cook up something quick for the e1000.
>
That would be nice, a common way for hw-vlans is a good thing.
Intel has also their own (kludgy?) way of doing hw-vlans in the current
driver?
- Pasi K?rkk?inen
^
. .
Linux
/ - \
Choice.of.the
.Next.Generation.
From: "Leech, Christopher" <[email protected]>
Date: Thu, 28 Feb 2002 13:57:07 -0800
> e1000 has a VLAN filter type on-chip, which complicates things a tiny bit.
The filtering is separate from the tagging. Filtering lets the hardware
ignore tagged packets for VLANs that it's not a member of. The vlan_group
structure isn't well laid out for this, but it would be possible to search
for non-NULL values in the vlan_devices array to get the VLAN IDs for
filtering. The driver would need to know when new VLAN IDs were added to
the group.
This is exactly the kind of thing I wanted people to discover
and discuss. Thanks for bringing this up.
It would be quite simple to hook back into your driver for this
purpose, proposed API:
/* For netdev->features */
#define NETIF_F_HW_VLAN_FILTER 1024
/* For NETIF_F_VLAN_RX_FILTER devices */
void (*vlan_rx_new_vid)(struct net_device *dev,
unsigned short vid);
We call dev->vlan_rx_kill_vid() in all cases because it has to
deal with interlocking, as described in an earlier email.
But if NETIF_F_HW_VLAN_FILTER is set, when new VLAN devices are
registered that go through your card, you will get a
dev->vlan_rx_new_vid() call.
I do not think you would need any more informatin than the
VID itself. If this is wrong, tell me now :-)
Sounds good to me, this should work nicely.
Chris
> -----Original Message-----
> From: David S. Miller [mailto:[email protected]]
> Sent: Thursday, February 28, 2002 2:57 PM
>
> This is exactly the kind of thing I wanted people to discover
> and discuss. Thanks for bringing this up.
>
> It would be quite simple to hook back into your driver for this
> purpose, proposed API:
>
> /* For netdev->features */
> #define NETIF_F_HW_VLAN_FILTER 1024
>
> /* For NETIF_F_VLAN_RX_FILTER devices */
> void (*vlan_rx_new_vid)(struct net_device *dev,
> unsigned short vid);
>
> We call dev->vlan_rx_kill_vid() in all cases because it has to
> deal with interlocking, as described in an earlier email.
>
> But if NETIF_F_HW_VLAN_FILTER is set, when new VLAN devices are
> registered that go through your card, you will get a
> dev->vlan_rx_new_vid() call.
>
> I do not think you would need any more informatin than the
> VID itself. If this is wrong, tell me now :-)
>
> e1000 has a VLAN filter type on-chip, which complicates things a tiny bit.
The filtering is separate from the tagging. Filtering lets the hardware
ignore tagged packets for VLANs that it's not a member of. The vlan_group
structure isn't well laid out for this, but it would be possible to search
for non-NULL values in the vlan_devices array to get the VLAN IDs for
filtering. The driver would need to know when new VLAN IDs were added to
the group.
Chris
--
Chris Leech <[email protected]>
Network Software Engineer
UNIX/Linux/Netware Development Group
LAN Access Division, Intel