RE: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of keeping it

the initialization as well as the vlan > registration. Sure, not having this hardware I didn't want to attempt a complicated change. I'll let you take care of this. -- Dave Johnson Starent Networks - To unsubscribe from this list: send the line "unsubscribe netdev" in

[PATCH 2/2] NET: Re-add VLAN tag for devices incapable of keeping it

s it's not clear exactly what change is needed: drivers/net/amd8111e.c drivers/net/cxgb3/* Signed-off-by: Dave Johnson <[EMAIL PROTECTED]> = drivers/net/acenic.c 1.77 vs edited = --- 1.77/drivers/net/acenic.c 2007-07-24 16:28:41 -04:00 +++ edited/drivers/net/acenic.c 2007-

[PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it

or devices that cannot do this the change will ensure tagged packets remain tagged in the network stack. Signed-off-by: Dave Johnson <[EMAIL PROTECTED]> --- Note, __vlan_hwaccel_rx() needed to move below __vlan_put_tag() so the change really isn't as big as it may look below. = in

Re: expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device?

Dave Johnson writes: > Ben Greear writes: > > Currently, VLAN devices offer the ability to 'reorder' the header > > and explicitly remove the VLAN header. I assume we keep this > > feature and have the AF_PACKET logic check the device flags to see > > if it

Re: expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device?

would only go to the vlan device not the base device. Not sure of an easy fix for this as af_packet can specifically bind to a specified base device. I don't this this would be much of an issue and probably doesn't need fixing. -- Dave Johnson Starent Networks - To unsubscri

expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device?

vior for these? Should vlan_hwaccel_receive_skb() shim a vlan tag back on the packet and send it to the base device if there is no vlan device to send to? Also, is it up to the individual driver to have a vlan tag on the packet if it uses netif_receive_skb() as in case 1 above? -- Dave Johnson Star

Re: [PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses

are not limited by ambiguity like the site-local addresses defined in >[ADDARCH]. -- Dave Johnson Starent Networks - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses

t/sctp/ipv6.c:sctp_v6_available() net/sctp/ipv6.c:sctp_v6_addr_valid() -- Dave Johnson Starent Networks - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http:/

[PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses

93 addresses if listening on IPV6_ADDR_ANY. There may be other users of ipv6_addr_type() that could also have problems. Signed-off-by: Dave Johnson <[EMAIL PROTECTED]> Cc: Srinivas Akkipeddi <[EMAIL PROTECTED]> = net/ipv6/addrconf_core.c 1.2 vs edited = --- 1.2/net/ipv6/addrconf_cor

[PATCH] improved locking performance in rt_run_flush()

there is a small change in that rt_free() is called while the lock is held where before it was called without the lock held. I don't think this should be an issue. Signed-off-by: Dave Johnson <[EMAIL PROTECTED]> = net/ipv4/route.c 1.162 vs edited = --- 1.162/net/ipv4/route.c