2008-07-08 14:23:36 +04:00
|
|
|
#include <linux/skbuff.h>
|
|
|
|
#include <linux/netdevice.h>
|
|
|
|
#include <linux/if_vlan.h>
|
2009-03-01 11:11:52 +03:00
|
|
|
#include <linux/netpoll.h>
|
2008-07-08 14:23:36 +04:00
|
|
|
#include "vlan.h"
|
|
|
|
|
|
|
|
/* VLAN rx hw acceleration helper. This acts like netif_{rx,receive_skb}(). */
|
|
|
|
int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
|
2008-07-08 14:24:44 +04:00
|
|
|
u16 vlan_tci, int polling)
|
2008-07-08 14:23:36 +04:00
|
|
|
{
|
vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
- Without the 8021q module loaded in the kernel, all 802.1p packets
(VLAN 0 but QoS tagging) are silently discarded (as expected, as
the protocol is not loaded).
- Without this patch in 8021q module, these packets are forwarded to
the module, but they are discarded also if VLAN 0 is not configured,
which should not be the default behaviour, as VLAN 0 is not really
a VLANed packet but a 802.1p packet. Defining VLAN 0 makes it almost
impossible to communicate with mixed 802.1p and non 802.1p devices on
the same network due to arp table issues.
- Changed logic to skip vlan specific code in vlan_skb_recv if VLAN
is 0 and we have not defined a VLAN with ID 0, but we accept the
packet with the encapsulated proto and pass it later to netif_rx.
- In the vlan device event handler, added some logic to add VLAN 0
to HW filter in devices that support it (this prevented any traffic
in VLAN 0 to reach the stack in e1000e with HW filter under 2.6.35,
and probably also with other HW filtered cards, so we fix it here).
- In the vlan unregister logic, prevent the elimination of VLAN 0
in devices with HW filter.
- The default behaviour is to ignore the VLAN 0 tagging and accept
the packet as if it was not tagged, but we can still define a
VLAN 0 if desired (so it is backwards compatible).
Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-07-19 02:38:44 +04:00
|
|
|
struct net_device *vlan_dev;
|
|
|
|
u16 vlan_id;
|
|
|
|
|
2009-03-01 11:11:52 +03:00
|
|
|
if (netpoll_rx(skb))
|
|
|
|
return NET_RX_DROP;
|
|
|
|
|
2010-03-19 07:16:45 +03:00
|
|
|
if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
|
2010-06-03 13:30:11 +04:00
|
|
|
skb->deliver_no_wcard = 1;
|
2008-07-08 14:23:36 +04:00
|
|
|
|
bonding: allow arp_ip_targets on separate vlans to use arp validation
This allows a bond device to specify an arp_ip_target as a host that is
not on the same vlan as the base bond device and still use arp
validation. A configuration like this, now works:
BONDING_OPTS="mode=active-backup arp_interval=1000 arp_ip_target=10.0.100.1 arp_validate=3"
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::213:21ff:febe:33e9/64 scope link
valid_lft forever preferred_lft forever
9: bond0.100@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
inet 10.0.100.2/24 brd 10.0.100.255 scope global bond0.100
inet6 fe80::213:21ff:febe:33e9/64 scope link
valid_lft forever preferred_lft forever
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
ARP Polling Interval (ms): 1000
ARP IP target/s (n.n.n.n form): 10.0.100.1
Slave Interface: eth1
MII Status: up
Link Failure Count: 1
Permanent HW addr: 00:40:05:30:ff:30
Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:13:21:be:33:e9
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-12-14 13:48:58 +03:00
|
|
|
skb->skb_iif = skb->dev->ifindex;
|
2009-11-13 09:33:11 +03:00
|
|
|
__vlan_hwaccel_put_tag(skb, vlan_tci);
|
vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
- Without the 8021q module loaded in the kernel, all 802.1p packets
(VLAN 0 but QoS tagging) are silently discarded (as expected, as
the protocol is not loaded).
- Without this patch in 8021q module, these packets are forwarded to
the module, but they are discarded also if VLAN 0 is not configured,
which should not be the default behaviour, as VLAN 0 is not really
a VLANed packet but a 802.1p packet. Defining VLAN 0 makes it almost
impossible to communicate with mixed 802.1p and non 802.1p devices on
the same network due to arp table issues.
- Changed logic to skip vlan specific code in vlan_skb_recv if VLAN
is 0 and we have not defined a VLAN with ID 0, but we accept the
packet with the encapsulated proto and pass it later to netif_rx.
- In the vlan device event handler, added some logic to add VLAN 0
to HW filter in devices that support it (this prevented any traffic
in VLAN 0 to reach the stack in e1000e with HW filter under 2.6.35,
and probably also with other HW filtered cards, so we fix it here).
- In the vlan unregister logic, prevent the elimination of VLAN 0
in devices with HW filter.
- The default behaviour is to ignore the VLAN 0 tagging and accept
the packet as if it was not tagged, but we can still define a
VLAN 0 if desired (so it is backwards compatible).
Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-07-19 02:38:44 +04:00
|
|
|
vlan_id = vlan_tci & VLAN_VID_MASK;
|
|
|
|
vlan_dev = vlan_group_get_device(grp, vlan_id);
|
2009-01-06 21:50:09 +03:00
|
|
|
|
vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
- Without the 8021q module loaded in the kernel, all 802.1p packets
(VLAN 0 but QoS tagging) are silently discarded (as expected, as
the protocol is not loaded).
- Without this patch in 8021q module, these packets are forwarded to
the module, but they are discarded also if VLAN 0 is not configured,
which should not be the default behaviour, as VLAN 0 is not really
a VLANed packet but a 802.1p packet. Defining VLAN 0 makes it almost
impossible to communicate with mixed 802.1p and non 802.1p devices on
the same network due to arp table issues.
- Changed logic to skip vlan specific code in vlan_skb_recv if VLAN
is 0 and we have not defined a VLAN with ID 0, but we accept the
packet with the encapsulated proto and pass it later to netif_rx.
- In the vlan device event handler, added some logic to add VLAN 0
to HW filter in devices that support it (this prevented any traffic
in VLAN 0 to reach the stack in e1000e with HW filter under 2.6.35,
and probably also with other HW filtered cards, so we fix it here).
- In the vlan unregister logic, prevent the elimination of VLAN 0
in devices with HW filter.
- The default behaviour is to ignore the VLAN 0 tagging and accept
the packet as if it was not tagged, but we can still define a
VLAN 0 if desired (so it is backwards compatible).
Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-07-19 02:38:44 +04:00
|
|
|
if (vlan_dev)
|
|
|
|
skb->dev = vlan_dev;
|
|
|
|
else if (vlan_id)
|
2009-01-06 21:50:09 +03:00
|
|
|
goto drop;
|
2008-11-05 01:49:57 +03:00
|
|
|
|
|
|
|
return (polling ? netif_receive_skb(skb) : netif_rx(skb));
|
2009-01-06 21:50:09 +03:00
|
|
|
|
|
|
|
drop:
|
|
|
|
dev_kfree_skb_any(skb);
|
|
|
|
return NET_RX_DROP;
|
2008-11-05 01:49:57 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__vlan_hwaccel_rx);
|
|
|
|
|
|
|
|
int vlan_hwaccel_do_receive(struct sk_buff *skb)
|
|
|
|
{
|
2009-01-06 21:50:09 +03:00
|
|
|
struct net_device *dev = skb->dev;
|
2009-11-17 07:53:09 +03:00
|
|
|
struct vlan_rx_stats *rx_stats;
|
2008-11-05 01:49:57 +03:00
|
|
|
|
2009-01-06 21:50:09 +03:00
|
|
|
skb->dev = vlan_dev_info(dev)->real_dev;
|
2008-07-15 09:49:30 +04:00
|
|
|
netif_nit_deliver(skb);
|
|
|
|
|
2008-11-05 01:49:57 +03:00
|
|
|
skb->dev = dev;
|
|
|
|
skb->priority = vlan_get_ingress_priority(dev, skb->vlan_tci);
|
2008-07-15 09:49:30 +04:00
|
|
|
skb->vlan_tci = 0;
|
2008-07-08 14:23:36 +04:00
|
|
|
|
2010-06-24 04:55:06 +04:00
|
|
|
rx_stats = this_cpu_ptr(vlan_dev_info(dev)->vlan_rx_stats);
|
2009-11-17 07:53:09 +03:00
|
|
|
|
2010-06-24 04:55:06 +04:00
|
|
|
u64_stats_update_begin(&rx_stats->syncp);
|
2009-11-17 07:53:09 +03:00
|
|
|
rx_stats->rx_packets++;
|
|
|
|
rx_stats->rx_bytes += skb->len;
|
2008-07-08 14:23:36 +04:00
|
|
|
|
|
|
|
switch (skb->pkt_type) {
|
|
|
|
case PACKET_BROADCAST:
|
|
|
|
break;
|
|
|
|
case PACKET_MULTICAST:
|
2010-06-24 04:55:06 +04:00
|
|
|
rx_stats->rx_multicast++;
|
2008-07-08 14:23:36 +04:00
|
|
|
break;
|
|
|
|
case PACKET_OTHERHOST:
|
|
|
|
/* Our lower layer thinks this is not local, let's make sure.
|
|
|
|
* This allows the VLAN to have a different MAC than the
|
|
|
|
* underlying device, and still route correctly. */
|
|
|
|
if (!compare_ether_addr(eth_hdr(skb)->h_dest,
|
2008-11-05 01:49:57 +03:00
|
|
|
dev->dev_addr))
|
2008-07-08 14:23:36 +04:00
|
|
|
skb->pkt_type = PACKET_HOST;
|
|
|
|
break;
|
2010-05-14 14:58:26 +04:00
|
|
|
}
|
2010-06-24 04:55:06 +04:00
|
|
|
u64_stats_update_end(&rx_stats->syncp);
|
2008-11-05 01:49:57 +03:00
|
|
|
return 0;
|
2008-07-08 14:23:36 +04:00
|
|
|
}
|
2008-07-08 14:23:57 +04:00
|
|
|
|
|
|
|
struct net_device *vlan_dev_real_dev(const struct net_device *dev)
|
|
|
|
{
|
|
|
|
return vlan_dev_info(dev)->real_dev;
|
|
|
|
}
|
2009-01-26 23:37:53 +03:00
|
|
|
EXPORT_SYMBOL(vlan_dev_real_dev);
|
2008-07-08 14:23:57 +04:00
|
|
|
|
|
|
|
u16 vlan_dev_vlan_id(const struct net_device *dev)
|
|
|
|
{
|
|
|
|
return vlan_dev_info(dev)->vlan_id;
|
|
|
|
}
|
2009-01-26 23:37:53 +03:00
|
|
|
EXPORT_SYMBOL(vlan_dev_vlan_id);
|
2009-01-06 21:50:09 +03:00
|
|
|
|
2009-10-29 10:17:09 +03:00
|
|
|
static gro_result_t
|
|
|
|
vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
|
|
|
|
unsigned int vlan_tci, struct sk_buff *skb)
|
2009-01-06 21:50:09 +03:00
|
|
|
{
|
|
|
|
struct sk_buff *p;
|
vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
- Without the 8021q module loaded in the kernel, all 802.1p packets
(VLAN 0 but QoS tagging) are silently discarded (as expected, as
the protocol is not loaded).
- Without this patch in 8021q module, these packets are forwarded to
the module, but they are discarded also if VLAN 0 is not configured,
which should not be the default behaviour, as VLAN 0 is not really
a VLANed packet but a 802.1p packet. Defining VLAN 0 makes it almost
impossible to communicate with mixed 802.1p and non 802.1p devices on
the same network due to arp table issues.
- Changed logic to skip vlan specific code in vlan_skb_recv if VLAN
is 0 and we have not defined a VLAN with ID 0, but we accept the
packet with the encapsulated proto and pass it later to netif_rx.
- In the vlan device event handler, added some logic to add VLAN 0
to HW filter in devices that support it (this prevented any traffic
in VLAN 0 to reach the stack in e1000e with HW filter under 2.6.35,
and probably also with other HW filtered cards, so we fix it here).
- In the vlan unregister logic, prevent the elimination of VLAN 0
in devices with HW filter.
- The default behaviour is to ignore the VLAN 0 tagging and accept
the packet as if it was not tagged, but we can still define a
VLAN 0 if desired (so it is backwards compatible).
Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-07-19 02:38:44 +04:00
|
|
|
struct net_device *vlan_dev;
|
|
|
|
u16 vlan_id;
|
2009-01-06 21:50:09 +03:00
|
|
|
|
2010-03-19 07:16:45 +03:00
|
|
|
if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
|
2010-06-03 13:30:11 +04:00
|
|
|
skb->deliver_no_wcard = 1;
|
2009-01-06 21:50:09 +03:00
|
|
|
|
bonding: allow arp_ip_targets on separate vlans to use arp validation
This allows a bond device to specify an arp_ip_target as a host that is
not on the same vlan as the base bond device and still use arp
validation. A configuration like this, now works:
BONDING_OPTS="mode=active-backup arp_interval=1000 arp_ip_target=10.0.100.1 arp_validate=3"
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::213:21ff:febe:33e9/64 scope link
valid_lft forever preferred_lft forever
9: bond0.100@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
inet 10.0.100.2/24 brd 10.0.100.255 scope global bond0.100
inet6 fe80::213:21ff:febe:33e9/64 scope link
valid_lft forever preferred_lft forever
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
ARP Polling Interval (ms): 1000
ARP IP target/s (n.n.n.n form): 10.0.100.1
Slave Interface: eth1
MII Status: up
Link Failure Count: 1
Permanent HW addr: 00:40:05:30:ff:30
Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:13:21:be:33:e9
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-12-14 13:48:58 +03:00
|
|
|
skb->skb_iif = skb->dev->ifindex;
|
2009-11-13 09:33:11 +03:00
|
|
|
__vlan_hwaccel_put_tag(skb, vlan_tci);
|
vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
- Without the 8021q module loaded in the kernel, all 802.1p packets
(VLAN 0 but QoS tagging) are silently discarded (as expected, as
the protocol is not loaded).
- Without this patch in 8021q module, these packets are forwarded to
the module, but they are discarded also if VLAN 0 is not configured,
which should not be the default behaviour, as VLAN 0 is not really
a VLANed packet but a 802.1p packet. Defining VLAN 0 makes it almost
impossible to communicate with mixed 802.1p and non 802.1p devices on
the same network due to arp table issues.
- Changed logic to skip vlan specific code in vlan_skb_recv if VLAN
is 0 and we have not defined a VLAN with ID 0, but we accept the
packet with the encapsulated proto and pass it later to netif_rx.
- In the vlan device event handler, added some logic to add VLAN 0
to HW filter in devices that support it (this prevented any traffic
in VLAN 0 to reach the stack in e1000e with HW filter under 2.6.35,
and probably also with other HW filtered cards, so we fix it here).
- In the vlan unregister logic, prevent the elimination of VLAN 0
in devices with HW filter.
- The default behaviour is to ignore the VLAN 0 tagging and accept
the packet as if it was not tagged, but we can still define a
VLAN 0 if desired (so it is backwards compatible).
Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-07-19 02:38:44 +04:00
|
|
|
vlan_id = vlan_tci & VLAN_VID_MASK;
|
|
|
|
vlan_dev = vlan_group_get_device(grp, vlan_id);
|
2009-01-06 21:50:09 +03:00
|
|
|
|
vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
- Without the 8021q module loaded in the kernel, all 802.1p packets
(VLAN 0 but QoS tagging) are silently discarded (as expected, as
the protocol is not loaded).
- Without this patch in 8021q module, these packets are forwarded to
the module, but they are discarded also if VLAN 0 is not configured,
which should not be the default behaviour, as VLAN 0 is not really
a VLANed packet but a 802.1p packet. Defining VLAN 0 makes it almost
impossible to communicate with mixed 802.1p and non 802.1p devices on
the same network due to arp table issues.
- Changed logic to skip vlan specific code in vlan_skb_recv if VLAN
is 0 and we have not defined a VLAN with ID 0, but we accept the
packet with the encapsulated proto and pass it later to netif_rx.
- In the vlan device event handler, added some logic to add VLAN 0
to HW filter in devices that support it (this prevented any traffic
in VLAN 0 to reach the stack in e1000e with HW filter under 2.6.35,
and probably also with other HW filtered cards, so we fix it here).
- In the vlan unregister logic, prevent the elimination of VLAN 0
in devices with HW filter.
- The default behaviour is to ignore the VLAN 0 tagging and accept
the packet as if it was not tagged, but we can still define a
VLAN 0 if desired (so it is backwards compatible).
Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-07-19 02:38:44 +04:00
|
|
|
if (vlan_dev)
|
|
|
|
skb->dev = vlan_dev;
|
|
|
|
else if (vlan_id)
|
2009-01-06 21:50:09 +03:00
|
|
|
goto drop;
|
|
|
|
|
|
|
|
for (p = napi->gro_list; p; p = p->next) {
|
2009-02-08 21:00:37 +03:00
|
|
|
NAPI_GRO_CB(p)->same_flow =
|
|
|
|
p->dev == skb->dev && !compare_ether_header(
|
|
|
|
skb_mac_header(p), skb_gro_mac_header(skb));
|
2009-01-06 21:50:09 +03:00
|
|
|
NAPI_GRO_CB(p)->flush = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return dev_gro_receive(napi, skb);
|
|
|
|
|
|
|
|
drop:
|
2009-03-16 20:50:02 +03:00
|
|
|
return GRO_DROP;
|
2009-01-06 21:50:09 +03:00
|
|
|
}
|
|
|
|
|
2009-10-30 07:36:53 +03:00
|
|
|
gro_result_t vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
|
|
|
|
unsigned int vlan_tci, struct sk_buff *skb)
|
2009-01-06 21:50:09 +03:00
|
|
|
{
|
2009-03-17 23:10:52 +03:00
|
|
|
if (netpoll_rx_on(skb))
|
2009-10-30 07:36:53 +03:00
|
|
|
return vlan_hwaccel_receive_skb(skb, grp, vlan_tci)
|
|
|
|
? GRO_DROP : GRO_NORMAL;
|
2009-03-17 23:10:52 +03:00
|
|
|
|
2009-01-29 17:19:50 +03:00
|
|
|
skb_gro_reset_offset(skb);
|
|
|
|
|
2009-01-29 17:19:48 +03:00
|
|
|
return napi_skb_finish(vlan_gro_common(napi, grp, vlan_tci, skb), skb);
|
2009-01-06 21:50:09 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(vlan_gro_receive);
|
|
|
|
|
2009-10-30 07:36:53 +03:00
|
|
|
gro_result_t vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
|
|
|
|
unsigned int vlan_tci)
|
2009-01-06 21:50:09 +03:00
|
|
|
{
|
2009-04-16 13:02:07 +04:00
|
|
|
struct sk_buff *skb = napi_frags_skb(napi);
|
2009-01-06 21:50:09 +03:00
|
|
|
|
|
|
|
if (!skb)
|
2009-10-30 07:36:53 +03:00
|
|
|
return GRO_DROP;
|
2009-01-06 21:50:09 +03:00
|
|
|
|
2009-04-13 08:41:01 +04:00
|
|
|
if (netpoll_rx_on(skb)) {
|
|
|
|
skb->protocol = eth_type_trans(skb, skb->dev);
|
2009-10-30 07:36:53 +03:00
|
|
|
return vlan_hwaccel_receive_skb(skb, grp, vlan_tci)
|
|
|
|
? GRO_DROP : GRO_NORMAL;
|
2009-04-13 08:41:01 +04:00
|
|
|
}
|
2009-03-17 23:10:52 +03:00
|
|
|
|
2009-01-29 17:19:48 +03:00
|
|
|
return napi_frags_finish(napi, skb,
|
|
|
|
vlan_gro_common(napi, grp, vlan_tci, skb));
|
2009-01-06 21:50:09 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(vlan_gro_frags);
|