* [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
@ 2011-04-02 10:26 Jiri Pirko
2011-04-02 15:55 ` Stephen Hemminger
2011-04-03 15:23 ` Nicolas de Pesloüan
0 siblings, 2 replies; 20+ messages in thread
From: Jiri Pirko @ 2011-04-02 10:26 UTC (permalink / raw)
To: netdev
Cc: davem, shemminger, kaber, fubar, eric.dumazet, nicolas.2p.debian,
andy, xiaosuo, jesse
Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.
For non-rx-vlan-hw-accel however, tagged skb goes thru whole
__netif_receive_skb, it's untagged in ptype_base hander and reinjected
This incosistency is fixed by this patch. Vlan untagging happens early in
__netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
see the skb like it was untagged by hw.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
include/linux/if_vlan.h | 10 ++-
net/8021q/vlan.c | 8 --
net/8021q/vlan.h | 2 -
net/8021q/vlan_core.c | 86 +++++++++++++++++++++++-
net/8021q/vlan_dev.c | 173 -----------------------------------------------
net/core/dev.c | 8 ++-
6 files changed, 100 insertions(+), 187 deletions(-)
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 635e1fa..998b299 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -132,7 +132,8 @@ extern u16 vlan_dev_vlan_id(const struct net_device *dev);
extern int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
u16 vlan_tci, int polling);
-extern bool vlan_hwaccel_do_receive(struct sk_buff **skb);
+extern bool vlan_do_receive(struct sk_buff **skb);
+extern struct sk_buff *vlan_untag(struct sk_buff *skb);
extern gro_result_t
vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
unsigned int vlan_tci, struct sk_buff *skb);
@@ -166,13 +167,18 @@ static inline int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
return NET_XMIT_SUCCESS;
}
-static inline bool vlan_hwaccel_do_receive(struct sk_buff **skb)
+static inline bool vlan_do_receive(struct sk_buff **skb)
{
if ((*skb)->vlan_tci & VLAN_VID_MASK)
(*skb)->pkt_type = PACKET_OTHERHOST;
return false;
}
+inline struct sk_buff *vlan_untag(struct sk_buff *skb)
+{
+ return skb;
+}
+
static inline gro_result_t
vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
unsigned int vlan_tci, struct sk_buff *skb)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 7850412..59f0a9d 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -49,11 +49,6 @@ const char vlan_version[] = DRV_VERSION;
static const char vlan_copyright[] = "Ben Greear <greearb@candelatech.com>";
static const char vlan_buggyright[] = "David S. Miller <davem@redhat.com>";
-static struct packet_type vlan_packet_type __read_mostly = {
- .type = cpu_to_be16(ETH_P_8021Q),
- .func = vlan_skb_recv, /* VLAN receive method */
-};
-
/* End of global variables definitions. */
static void vlan_group_free(struct vlan_group *grp)
@@ -688,7 +683,6 @@ static int __init vlan_proto_init(void)
if (err < 0)
goto err4;
- dev_add_pack(&vlan_packet_type);
vlan_ioctl_set(vlan_ioctl_handler);
return 0;
@@ -709,8 +703,6 @@ static void __exit vlan_cleanup_module(void)
unregister_netdevice_notifier(&vlan_notifier_block);
- dev_remove_pack(&vlan_packet_type);
-
unregister_pernet_subsys(&vlan_net_ops);
rcu_barrier(); /* Wait for completion of call_rcu()'s */
diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
index 5687c9b..c3408de 100644
--- a/net/8021q/vlan.h
+++ b/net/8021q/vlan.h
@@ -75,8 +75,6 @@ static inline struct vlan_dev_info *vlan_dev_info(const struct net_device *dev)
}
/* found in vlan_dev.c */
-int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
- struct packet_type *ptype, struct net_device *orig_dev);
void vlan_dev_set_ingress_priority(const struct net_device *dev,
u32 skb_prio, u16 vlan_prio);
int vlan_dev_set_egress_priority(const struct net_device *dev,
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index ce8e3ab..bc83ecc 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -4,7 +4,7 @@
#include <linux/netpoll.h>
#include "vlan.h"
-bool vlan_hwaccel_do_receive(struct sk_buff **skbp)
+bool vlan_do_receive(struct sk_buff **skbp)
{
struct sk_buff *skb = *skbp;
u16 vlan_id = skb->vlan_tci & VLAN_VID_MASK;
@@ -88,3 +88,87 @@ gro_result_t vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
return napi_gro_frags(napi);
}
EXPORT_SYMBOL(vlan_gro_frags);
+
+static inline struct sk_buff *vlan_check_reorder_header(struct sk_buff *skb)
+{
+ if (vlan_dev_info(skb->dev)->flags & VLAN_FLAG_REORDER_HDR) {
+ if (skb_cow(skb, skb_headroom(skb)) < 0)
+ skb = NULL;
+ if (skb) {
+ /* Lifted from Gleb's VLAN code... */
+ memmove(skb->data - ETH_HLEN,
+ skb->data - VLAN_ETH_HLEN, 12);
+ skb->mac_header += VLAN_HLEN;
+ }
+ }
+ return skb;
+}
+
+static inline void vlan_set_encap_proto(struct sk_buff *skb,
+ struct vlan_hdr *vhdr)
+{
+ __be16 proto;
+ unsigned char *rawp;
+
+ /*
+ * Was a VLAN packet, grab the encapsulated protocol, which the layer
+ * three protocols care about.
+ */
+
+ proto = vhdr->h_vlan_encapsulated_proto;
+ if (ntohs(proto) >= 1536) {
+ skb->protocol = proto;
+ return;
+ }
+
+ rawp = skb->data;
+ if (*(unsigned short *) rawp == 0xFFFF)
+ /*
+ * This is a magic hack to spot IPX packets. Older Novell
+ * breaks the protocol design and runs IPX over 802.3 without
+ * an 802.2 LLC layer. We look for FFFF which isn't a used
+ * 802.2 SSAP/DSAP. This won't work for fault tolerant netware
+ * but does for the rest.
+ */
+ skb->protocol = htons(ETH_P_802_3);
+ else
+ /*
+ * Real 802.2 LLC
+ */
+ skb->protocol = htons(ETH_P_802_2);
+}
+
+struct sk_buff *vlan_untag(struct sk_buff *skb)
+{
+ struct vlan_hdr *vhdr;
+ u16 vlan_tci;
+
+ if (unlikely(vlan_tx_tag_present(skb))) {
+ /* vlan_tci is already set-up so leave this for another time */
+ return skb;
+ }
+
+ skb = skb_share_check(skb, GFP_ATOMIC);
+ if (unlikely(!skb))
+ goto err_free;
+
+ if (unlikely(!pskb_may_pull(skb, VLAN_HLEN)))
+ goto err_free;
+
+ vhdr = (struct vlan_hdr *) skb->data;
+ vlan_tci = ntohs(vhdr->h_vlan_TCI);
+ __vlan_hwaccel_put_tag(skb, vlan_tci);
+
+ skb_pull_rcsum(skb, VLAN_HLEN);
+ vlan_set_encap_proto(skb, vhdr);
+
+ skb = vlan_check_reorder_header(skb);
+ if (unlikely(!skb))
+ goto err_free;
+
+ return skb;
+
+err_free:
+ kfree_skb(skb);
+ return NULL;
+}
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index e34ea9e..b4f061f 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -65,179 +65,6 @@ static int vlan_dev_rebuild_header(struct sk_buff *skb)
return 0;
}
-static inline struct sk_buff *vlan_check_reorder_header(struct sk_buff *skb)
-{
- if (vlan_dev_info(skb->dev)->flags & VLAN_FLAG_REORDER_HDR) {
- if (skb_cow(skb, skb_headroom(skb)) < 0)
- skb = NULL;
- if (skb) {
- /* Lifted from Gleb's VLAN code... */
- memmove(skb->data - ETH_HLEN,
- skb->data - VLAN_ETH_HLEN, 12);
- skb->mac_header += VLAN_HLEN;
- }
- }
-
- return skb;
-}
-
-static inline void vlan_set_encap_proto(struct sk_buff *skb,
- struct vlan_hdr *vhdr)
-{
- __be16 proto;
- unsigned char *rawp;
-
- /*
- * Was a VLAN packet, grab the encapsulated protocol, which the layer
- * three protocols care about.
- */
-
- proto = vhdr->h_vlan_encapsulated_proto;
- if (ntohs(proto) >= 1536) {
- skb->protocol = proto;
- return;
- }
-
- rawp = skb->data;
- if (*(unsigned short *)rawp == 0xFFFF)
- /*
- * This is a magic hack to spot IPX packets. Older Novell
- * breaks the protocol design and runs IPX over 802.3 without
- * an 802.2 LLC layer. We look for FFFF which isn't a used
- * 802.2 SSAP/DSAP. This won't work for fault tolerant netware
- * but does for the rest.
- */
- skb->protocol = htons(ETH_P_802_3);
- else
- /*
- * Real 802.2 LLC
- */
- skb->protocol = htons(ETH_P_802_2);
-}
-
-/*
- * Determine the packet's protocol ID. The rule here is that we
- * assume 802.3 if the type field is short enough to be a length.
- * This is normal practice and works for any 'now in use' protocol.
- *
- * Also, at this point we assume that we ARE dealing exclusively with
- * VLAN packets, or packets that should be made into VLAN packets based
- * on a default VLAN ID.
- *
- * NOTE: Should be similar to ethernet/eth.c.
- *
- * SANITY NOTE: This method is called when a packet is moving up the stack
- * towards userland. To get here, it would have already passed
- * through the ethernet/eth.c eth_type_trans() method.
- * SANITY NOTE 2: We are referencing to the VLAN_HDR frields, which MAY be
- * stored UNALIGNED in the memory. RISC systems don't like
- * such cases very much...
- * SANITY NOTE 2a: According to Dave Miller & Alexey, it will always be
- * aligned, so there doesn't need to be any of the unaligned
- * stuff. It has been commented out now... --Ben
- *
- */
-int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
- struct packet_type *ptype, struct net_device *orig_dev)
-{
- struct vlan_hdr *vhdr;
- struct vlan_pcpu_stats *rx_stats;
- struct net_device *vlan_dev;
- u16 vlan_id;
- u16 vlan_tci;
-
- skb = skb_share_check(skb, GFP_ATOMIC);
- if (skb == NULL)
- goto err_free;
-
- if (unlikely(!pskb_may_pull(skb, VLAN_HLEN)))
- goto err_free;
-
- vhdr = (struct vlan_hdr *)skb->data;
- vlan_tci = ntohs(vhdr->h_vlan_TCI);
- vlan_id = vlan_tci & VLAN_VID_MASK;
-
- rcu_read_lock();
- vlan_dev = vlan_find_dev(dev, vlan_id);
-
- /* If the VLAN device is defined, we use it.
- * If not, and the VID is 0, it is a 802.1p packet (not
- * really a VLAN), so we will just netif_rx it later to the
- * original interface, but with the skb->proto set to the
- * wrapped proto: we do nothing here.
- */
-
- if (!vlan_dev) {
- if (vlan_id) {
- pr_debug("%s: ERROR: No net_device for VID: %u on dev: %s\n",
- __func__, vlan_id, dev->name);
- goto err_unlock;
- }
- rx_stats = NULL;
- } else {
- skb->dev = vlan_dev;
-
- rx_stats = this_cpu_ptr(vlan_dev_info(skb->dev)->vlan_pcpu_stats);
-
- u64_stats_update_begin(&rx_stats->syncp);
- rx_stats->rx_packets++;
- rx_stats->rx_bytes += skb->len;
-
- skb->priority = vlan_get_ingress_priority(skb->dev, vlan_tci);
-
- pr_debug("%s: priority: %u for TCI: %hu\n",
- __func__, skb->priority, vlan_tci);
-
- switch (skb->pkt_type) {
- case PACKET_BROADCAST:
- /* Yeah, stats collect these together.. */
- /* stats->broadcast ++; // no such counter :-( */
- break;
-
- case PACKET_MULTICAST:
- rx_stats->rx_multicast++;
- 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,
- skb->dev->dev_addr))
- skb->pkt_type = PACKET_HOST;
- break;
- default:
- break;
- }
- u64_stats_update_end(&rx_stats->syncp);
- }
-
- skb_pull_rcsum(skb, VLAN_HLEN);
- vlan_set_encap_proto(skb, vhdr);
-
- if (vlan_dev) {
- skb = vlan_check_reorder_header(skb);
- if (!skb) {
- rx_stats->rx_errors++;
- goto err_unlock;
- }
- }
-
- netif_rx(skb);
-
- rcu_read_unlock();
- return NET_RX_SUCCESS;
-
-err_unlock:
- rcu_read_unlock();
-err_free:
- atomic_long_inc(&dev->rx_dropped);
- kfree_skb(skb);
- return NET_RX_DROP;
-}
-
static inline u16
vlan_dev_get_egress_qos_mask(struct net_device *dev, struct sk_buff *skb)
{
diff --git a/net/core/dev.c b/net/core/dev.c
index 3da9fb0..bfe9fce 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3130,6 +3130,12 @@ another_round:
__this_cpu_inc(softnet_data.processed);
+ if (skb->protocol == cpu_to_be16(ETH_P_8021Q)) {
+ skb = vlan_untag(skb);
+ if (unlikely(!skb))
+ goto out;
+ }
+
#ifdef CONFIG_NET_CLS_ACT
if (skb->tc_verd & TC_NCLS) {
skb->tc_verd = CLR_TC_NCLS(skb->tc_verd);
@@ -3177,7 +3183,7 @@ ncls:
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = NULL;
}
- if (vlan_hwaccel_do_receive(&skb)) {
+ if (vlan_do_receive(&skb)) {
ret = __netif_receive_skb(skb);
goto out;
} else if (unlikely(!skb))
--
1.7.4
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-02 10:26 [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel Jiri Pirko
@ 2011-04-02 15:55 ` Stephen Hemminger
2011-04-02 18:27 ` Jiri Pirko
2011-04-03 15:23 ` Nicolas de Pesloüan
1 sibling, 1 reply; 20+ messages in thread
From: Stephen Hemminger @ 2011-04-02 15:55 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, kaber, fubar, eric.dumazet, nicolas.2p.debian,
andy, xiaosuo, jesse
On Sat, 2 Apr 2011 12:26:06 +0200
Jiri Pirko <jpirko@redhat.com> wrote:
> Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
> enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
> vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.
>
> For non-rx-vlan-hw-accel however, tagged skb goes thru whole
> __netif_receive_skb, it's untagged in ptype_base hander and reinjected
>
> This incosistency is fixed by this patch. Vlan untagging happens early in
> __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
> see the skb like it was untagged by hw.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> ---
> include/linux/if_vlan.h | 10 ++-
> net/8021q/vlan.c | 8 --
> net/8021q/vlan.h | 2 -
> net/8021q/vlan_core.c | 86 +++++++++++++++++++++++-
> net/8021q/vlan_dev.c | 173 -----------------------------------------------
> net/core/dev.c | 8 ++-
> 6 files changed, 100 insertions(+), 187 deletions(-)
>
> diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
> index 635e1fa..998b299 100644
> --- a/include/linux/if_vlan.h
> +++ b/include/linux/if_vlan.h
> @@ -132,7 +132,8 @@ extern u16 vlan_dev_vlan_id(const struct net_device *dev);
>
> extern int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
> u16 vlan_tci, int polling);
> -extern bool vlan_hwaccel_do_receive(struct sk_buff **skb);
> +extern bool vlan_do_receive(struct sk_buff **skb);
> +extern struct sk_buff *vlan_untag(struct sk_buff *skb);
> extern gro_result_t
> vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
> unsigned int vlan_tci, struct sk_buff *skb);
> @@ -166,13 +167,18 @@ static inline int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
> return NET_XMIT_SUCCESS;
> }
>
> -static inline bool vlan_hwaccel_do_receive(struct sk_buff **skb)
> +static inline bool vlan_do_receive(struct sk_buff **skb)
> {
> if ((*skb)->vlan_tci & VLAN_VID_MASK)
> (*skb)->pkt_type = PACKET_OTHERHOST;
> return false;
> }
Why the added unnecessary indirection
> +inline struct sk_buff *vlan_untag(struct sk_buff *skb)
> +{
> + return skb;
> +}
This adds no value.
> static inline gro_result_t
> vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
> unsigned int vlan_tci, struct sk_buff *skb)
> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
> index 7850412..59f0a9d 100644
> --- a/net/8021q/vlan.c
> +++ b/net/8021q/vlan.c
> @@ -49,11 +49,6 @@ const char vlan_version[] = DRV_VERSION;
> static const char vlan_copyright[] = "Ben Greear <greearb@candelatech.com>";
> static const char vlan_buggyright[] = "David S. Miller <davem@redhat.com>";
>
> -static struct packet_type vlan_packet_type __read_mostly = {
> - .type = cpu_to_be16(ETH_P_8021Q),
> - .func = vlan_skb_recv, /* VLAN receive method */
> -};
> -
> /* End of global variables definitions. */
>
> static void vlan_group_free(struct vlan_group *grp)
> @@ -688,7 +683,6 @@ static int __init vlan_proto_init(void)
> if (err < 0)
> goto err4;
>
> - dev_add_pack(&vlan_packet_type);
> vlan_ioctl_set(vlan_ioctl_handler);
> return 0;
>
> @@ -709,8 +703,6 @@ static void __exit vlan_cleanup_module(void)
>
> unregister_netdevice_notifier(&vlan_notifier_block);
>
> - dev_remove_pack(&vlan_packet_type);
> -
> unregister_pernet_subsys(&vlan_net_ops);
> rcu_barrier(); /* Wait for completion of call_rcu()'s */
>
> diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
> index 5687c9b..c3408de 100644
> --- a/net/8021q/vlan.h
> +++ b/net/8021q/vlan.h
> @@ -75,8 +75,6 @@ static inline struct vlan_dev_info *vlan_dev_info(const struct net_device *dev)
> }
>
> /* found in vlan_dev.c */
> -int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
> - struct packet_type *ptype, struct net_device *orig_dev);
> void vlan_dev_set_ingress_priority(const struct net_device *dev,
> u32 skb_prio, u16 vlan_prio);
> int vlan_dev_set_egress_priority(const struct net_device *dev,
> diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
> index ce8e3ab..bc83ecc 100644
> --- a/net/8021q/vlan_core.c
> +++ b/net/8021q/vlan_core.c
> @@ -4,7 +4,7 @@
> #include <linux/netpoll.h>
> #include "vlan.h"
>
> -bool vlan_hwaccel_do_receive(struct sk_buff **skbp)
> +bool vlan_do_receive(struct sk_buff **skbp)
> {
> struct sk_buff *skb = *skbp;
> u16 vlan_id = skb->vlan_tci & VLAN_VID_MASK;
> @@ -88,3 +88,87 @@ gro_result_t vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
> return napi_gro_frags(napi);
> }
> EXPORT_SYMBOL(vlan_gro_frags);
> +
> +static inline struct sk_buff *vlan_check_reorder_header(struct sk_buff *skb)
> +{
> + if (vlan_dev_info(skb->dev)->flags & VLAN_FLAG_REORDER_HDR) {
> + if (skb_cow(skb, skb_headroom(skb)) < 0)
> + skb = NULL;
> + if (skb) {
> + /* Lifted from Gleb's VLAN code... */
> + memmove(skb->data - ETH_HLEN,
> + skb->data - VLAN_ETH_HLEN, 12);
> + skb->mac_header += VLAN_HLEN;
> + }
> + }
> + return skb;
> +}
Do not mark code as 'static inline' let compiler decide.
> +static inline void vlan_set_encap_proto(struct sk_buff *skb,
> + struct vlan_hdr *vhdr)
> +{
> + __be16 proto;
> + unsigned char *rawp;
> +
> + /*
> + * Was a VLAN packet, grab the encapsulated protocol, which the layer
> + * three protocols care about.
> + */
> +
> + proto = vhdr->h_vlan_encapsulated_proto;
> + if (ntohs(proto) >= 1536) {
> + skb->protocol = proto;
> + return;
> + }
> +
> + rawp = skb->data;
> + if (*(unsigned short *) rawp == 0xFFFF)
> + /*
> + * This is a magic hack to spot IPX packets. Older Novell
> + * breaks the protocol design and runs IPX over 802.3 without
> + * an 802.2 LLC layer. We look for FFFF which isn't a used
> + * 802.2 SSAP/DSAP. This won't work for fault tolerant netware
> + * but does for the rest.
> + */
> + skb->protocol = htons(ETH_P_802_3);
> + else
> + /*
> + * Real 802.2 LLC
> + */
> + skb->protocol = htons(ETH_P_802_2);
> +}
What about doublely tagged packets?
> +struct sk_buff *vlan_untag(struct sk_buff *skb)
> +{
> + struct vlan_hdr *vhdr;
> + u16 vlan_tci;
> +
> + if (unlikely(vlan_tx_tag_present(skb))) {
> + /* vlan_tci is already set-up so leave this for another time */
> + return skb;
> + }
> +
> + skb = skb_share_check(skb, GFP_ATOMIC);
> + if (unlikely(!skb))
> + goto err_free;
> +
> + if (unlikely(!pskb_may_pull(skb, VLAN_HLEN)))
> + goto err_free;
> +
> + vhdr = (struct vlan_hdr *) skb->data;
> + vlan_tci = ntohs(vhdr->h_vlan_TCI);
> + __vlan_hwaccel_put_tag(skb, vlan_tci);
> +
> + skb_pull_rcsum(skb, VLAN_HLEN);
> + vlan_set_encap_proto(skb, vhdr);
> +
> + skb = vlan_check_reorder_header(skb);
> + if (unlikely(!skb))
> + goto err_free;
> +
> + return skb;
> +
> +err_free:
> + kfree_skb(skb);
> + return NULL;
> +}
> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> index e34ea9e..b4f061f 100644
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -65,179 +65,6 @@ static int vlan_dev_rebuild_header(struct sk_buff *skb)
> return 0;
> }
>
> -static inline struct sk_buff *vlan_check_reorder_header(struct sk_buff *skb)
> -{
> - if (vlan_dev_info(skb->dev)->flags & VLAN_FLAG_REORDER_HDR) {
> - if (skb_cow(skb, skb_headroom(skb)) < 0)
> - skb = NULL;
> - if (skb) {
> - /* Lifted from Gleb's VLAN code... */
> - memmove(skb->data - ETH_HLEN,
> - skb->data - VLAN_ETH_HLEN, 12);
> - skb->mac_header += VLAN_HLEN;
> - }
> - }
> -
> - return skb;
> -}
> -
> -static inline void vlan_set_encap_proto(struct sk_buff *skb,
> - struct vlan_hdr *vhdr)
> -{
> - __be16 proto;
> - unsigned char *rawp;
> -
> - /*
> - * Was a VLAN packet, grab the encapsulated protocol, which the layer
> - * three protocols care about.
> - */
> -
> - proto = vhdr->h_vlan_encapsulated_proto;
> - if (ntohs(proto) >= 1536) {
> - skb->protocol = proto;
> - return;
> - }
> -
> - rawp = skb->data;
> - if (*(unsigned short *)rawp == 0xFFFF)
> - /*
> - * This is a magic hack to spot IPX packets. Older Novell
> - * breaks the protocol design and runs IPX over 802.3 without
> - * an 802.2 LLC layer. We look for FFFF which isn't a used
> - * 802.2 SSAP/DSAP. This won't work for fault tolerant netware
> - * but does for the rest.
> - */
> - skb->protocol = htons(ETH_P_802_3);
> - else
> - /*
> - * Real 802.2 LLC
> - */
> - skb->protocol = htons(ETH_P_802_2);
> -}
> -
> -/*
> - * Determine the packet's protocol ID. The rule here is that we
> - * assume 802.3 if the type field is short enough to be a length.
> - * This is normal practice and works for any 'now in use' protocol.
> - *
> - * Also, at this point we assume that we ARE dealing exclusively with
> - * VLAN packets, or packets that should be made into VLAN packets based
> - * on a default VLAN ID.
> - *
> - * NOTE: Should be similar to ethernet/eth.c.
> - *
> - * SANITY NOTE: This method is called when a packet is moving up the stack
> - * towards userland. To get here, it would have already passed
> - * through the ethernet/eth.c eth_type_trans() method.
> - * SANITY NOTE 2: We are referencing to the VLAN_HDR frields, which MAY be
> - * stored UNALIGNED in the memory. RISC systems don't like
> - * such cases very much...
> - * SANITY NOTE 2a: According to Dave Miller & Alexey, it will always be
> - * aligned, so there doesn't need to be any of the unaligned
> - * stuff. It has been commented out now... --Ben
> - *
> - */
> -int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
> - struct packet_type *ptype, struct net_device *orig_dev)
> -{
> - struct vlan_hdr *vhdr;
> - struct vlan_pcpu_stats *rx_stats;
> - struct net_device *vlan_dev;
> - u16 vlan_id;
> - u16 vlan_tci;
> -
> - skb = skb_share_check(skb, GFP_ATOMIC);
> - if (skb == NULL)
> - goto err_free;
> -
> - if (unlikely(!pskb_may_pull(skb, VLAN_HLEN)))
> - goto err_free;
> -
> - vhdr = (struct vlan_hdr *)skb->data;
> - vlan_tci = ntohs(vhdr->h_vlan_TCI);
> - vlan_id = vlan_tci & VLAN_VID_MASK;
> -
> - rcu_read_lock();
> - vlan_dev = vlan_find_dev(dev, vlan_id);
> -
> - /* If the VLAN device is defined, we use it.
> - * If not, and the VID is 0, it is a 802.1p packet (not
> - * really a VLAN), so we will just netif_rx it later to the
> - * original interface, but with the skb->proto set to the
> - * wrapped proto: we do nothing here.
> - */
> -
> - if (!vlan_dev) {
> - if (vlan_id) {
> - pr_debug("%s: ERROR: No net_device for VID: %u on dev: %s\n",
> - __func__, vlan_id, dev->name);
> - goto err_unlock;
> - }
> - rx_stats = NULL;
> - } else {
> - skb->dev = vlan_dev;
> -
> - rx_stats = this_cpu_ptr(vlan_dev_info(skb->dev)->vlan_pcpu_stats);
> -
> - u64_stats_update_begin(&rx_stats->syncp);
> - rx_stats->rx_packets++;
> - rx_stats->rx_bytes += skb->len;
> -
> - skb->priority = vlan_get_ingress_priority(skb->dev, vlan_tci);
> -
> - pr_debug("%s: priority: %u for TCI: %hu\n",
> - __func__, skb->priority, vlan_tci);
> -
> - switch (skb->pkt_type) {
> - case PACKET_BROADCAST:
> - /* Yeah, stats collect these together.. */
> - /* stats->broadcast ++; // no such counter :-( */
> - break;
> -
> - case PACKET_MULTICAST:
> - rx_stats->rx_multicast++;
> - 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,
> - skb->dev->dev_addr))
> - skb->pkt_type = PACKET_HOST;
> - break;
> - default:
> - break;
> - }
> - u64_stats_update_end(&rx_stats->syncp);
> - }
> -
> - skb_pull_rcsum(skb, VLAN_HLEN);
> - vlan_set_encap_proto(skb, vhdr);
> -
> - if (vlan_dev) {
> - skb = vlan_check_reorder_header(skb);
> - if (!skb) {
> - rx_stats->rx_errors++;
> - goto err_unlock;
> - }
> - }
> -
> - netif_rx(skb);
> -
> - rcu_read_unlock();
> - return NET_RX_SUCCESS;
> -
> -err_unlock:
> - rcu_read_unlock();
> -err_free:
> - atomic_long_inc(&dev->rx_dropped);
> - kfree_skb(skb);
> - return NET_RX_DROP;
> -}
> -
> static inline u16
> vlan_dev_get_egress_qos_mask(struct net_device *dev, struct sk_buff *skb)
> {
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 3da9fb0..bfe9fce 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3130,6 +3130,12 @@ another_round:
>
> __this_cpu_inc(softnet_data.processed);
>
> + if (skb->protocol == cpu_to_be16(ETH_P_8021Q)) {
> + skb = vlan_untag(skb);
> + if (unlikely(!skb))
> + goto out;
> + }
This becomes a NOP, why is it here?
> #ifdef CONFIG_NET_CLS_ACT
> if (skb->tc_verd & TC_NCLS) {
> skb->tc_verd = CLR_TC_NCLS(skb->tc_verd);
> @@ -3177,7 +3183,7 @@ ncls:
> ret = deliver_skb(skb, pt_prev, orig_dev);
> pt_prev = NULL;
> }
> - if (vlan_hwaccel_do_receive(&skb)) {
> + if (vlan_do_receive(&skb)) {
> ret = __netif_receive_skb(skb);
> goto out;
> } else if (unlikely(!skb))
Why rename the function?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-02 15:55 ` Stephen Hemminger
@ 2011-04-02 18:27 ` Jiri Pirko
2011-04-03 9:27 ` Nicolas de Pesloüan
0 siblings, 1 reply; 20+ messages in thread
From: Jiri Pirko @ 2011-04-02 18:27 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, davem, kaber, fubar, eric.dumazet, nicolas.2p.debian,
andy, xiaosuo, jesse
Sat, Apr 02, 2011 at 05:55:24PM CEST, shemminger@linux-foundation.org wrote:
>On Sat, 2 Apr 2011 12:26:06 +0200
>Jiri Pirko <jpirko@redhat.com> wrote:
>
>> Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
>> enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
>> vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.
>>
>> For non-rx-vlan-hw-accel however, tagged skb goes thru whole
>> __netif_receive_skb, it's untagged in ptype_base hander and reinjected
>>
>> This incosistency is fixed by this patch. Vlan untagging happens early in
>> __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
>> see the skb like it was untagged by hw.
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>> ---
>> include/linux/if_vlan.h | 10 ++-
>> net/8021q/vlan.c | 8 --
>> net/8021q/vlan.h | 2 -
>> net/8021q/vlan_core.c | 86 +++++++++++++++++++++++-
>> net/8021q/vlan_dev.c | 173 -----------------------------------------------
>> net/core/dev.c | 8 ++-
>> 6 files changed, 100 insertions(+), 187 deletions(-)
>>
>> diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
>> index 635e1fa..998b299 100644
>> --- a/include/linux/if_vlan.h
>> +++ b/include/linux/if_vlan.h
>> @@ -132,7 +132,8 @@ extern u16 vlan_dev_vlan_id(const struct net_device *dev);
>>
>> extern int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
>> u16 vlan_tci, int polling);
>> -extern bool vlan_hwaccel_do_receive(struct sk_buff **skb);
>> +extern bool vlan_do_receive(struct sk_buff **skb);
>> +extern struct sk_buff *vlan_untag(struct sk_buff *skb);
>> extern gro_result_t
>> vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
>> unsigned int vlan_tci, struct sk_buff *skb);
>> @@ -166,13 +167,18 @@ static inline int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
>> return NET_XMIT_SUCCESS;
>> }
>>
>> -static inline bool vlan_hwaccel_do_receive(struct sk_buff **skb)
>> +static inline bool vlan_do_receive(struct sk_buff **skb)
>> {
>> if ((*skb)->vlan_tci & VLAN_VID_MASK)
>> (*skb)->pkt_type = PACKET_OTHERHOST;
>> return false;
>> }
>
>Why the added unnecessary indirection
I do not understand what do you mean.
>
>
>> +inline struct sk_buff *vlan_untag(struct sk_buff *skb)
>> +{
>> + return skb;
>> +}
>
>This adds no value.
Nod, it should not. That's why this is in else of:
#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
>
>> static inline gro_result_t
>> vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
>> unsigned int vlan_tci, struct sk_buff *skb)
>> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
>> index 7850412..59f0a9d 100644
>> --- a/net/8021q/vlan.c
>> +++ b/net/8021q/vlan.c
>> @@ -49,11 +49,6 @@ const char vlan_version[] = DRV_VERSION;
>> static const char vlan_copyright[] = "Ben Greear <greearb@candelatech.com>";
>> static const char vlan_buggyright[] = "David S. Miller <davem@redhat.com>";
>>
>> -static struct packet_type vlan_packet_type __read_mostly = {
>> - .type = cpu_to_be16(ETH_P_8021Q),
>> - .func = vlan_skb_recv, /* VLAN receive method */
>> -};
>> -
>> /* End of global variables definitions. */
>>
>> static void vlan_group_free(struct vlan_group *grp)
>> @@ -688,7 +683,6 @@ static int __init vlan_proto_init(void)
>> if (err < 0)
>> goto err4;
>>
>> - dev_add_pack(&vlan_packet_type);
>> vlan_ioctl_set(vlan_ioctl_handler);
>> return 0;
>>
>> @@ -709,8 +703,6 @@ static void __exit vlan_cleanup_module(void)
>>
>> unregister_netdevice_notifier(&vlan_notifier_block);
>>
>> - dev_remove_pack(&vlan_packet_type);
>> -
>> unregister_pernet_subsys(&vlan_net_ops);
>> rcu_barrier(); /* Wait for completion of call_rcu()'s */
>>
>> diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
>> index 5687c9b..c3408de 100644
>> --- a/net/8021q/vlan.h
>> +++ b/net/8021q/vlan.h
>> @@ -75,8 +75,6 @@ static inline struct vlan_dev_info *vlan_dev_info(const struct net_device *dev)
>> }
>>
>> /* found in vlan_dev.c */
>> -int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
>> - struct packet_type *ptype, struct net_device *orig_dev);
>> void vlan_dev_set_ingress_priority(const struct net_device *dev,
>> u32 skb_prio, u16 vlan_prio);
>> int vlan_dev_set_egress_priority(const struct net_device *dev,
>> diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
>> index ce8e3ab..bc83ecc 100644
>> --- a/net/8021q/vlan_core.c
>> +++ b/net/8021q/vlan_core.c
>> @@ -4,7 +4,7 @@
>> #include <linux/netpoll.h>
>> #include "vlan.h"
>>
>> -bool vlan_hwaccel_do_receive(struct sk_buff **skbp)
>> +bool vlan_do_receive(struct sk_buff **skbp)
>> {
>> struct sk_buff *skb = *skbp;
>> u16 vlan_id = skb->vlan_tci & VLAN_VID_MASK;
>> @@ -88,3 +88,87 @@ gro_result_t vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
>> return napi_gro_frags(napi);
>> }
>> EXPORT_SYMBOL(vlan_gro_frags);
>> +
>> +static inline struct sk_buff *vlan_check_reorder_header(struct sk_buff *skb)
>> +{
>> + if (vlan_dev_info(skb->dev)->flags & VLAN_FLAG_REORDER_HDR) {
>> + if (skb_cow(skb, skb_headroom(skb)) < 0)
>> + skb = NULL;
>> + if (skb) {
>> + /* Lifted from Gleb's VLAN code... */
>> + memmove(skb->data - ETH_HLEN,
>> + skb->data - VLAN_ETH_HLEN, 12);
>> + skb->mac_header += VLAN_HLEN;
>> + }
>> + }
>> + return skb;
>> +}
>
>Do not mark code as 'static inline' let compiler decide.
I just moved this function from vlan_dev.c as it is. No problem to
change this.
>
>> +static inline void vlan_set_encap_proto(struct sk_buff *skb,
>> + struct vlan_hdr *vhdr)
>> +{
>> + __be16 proto;
>> + unsigned char *rawp;
>> +
>> + /*
>> + * Was a VLAN packet, grab the encapsulated protocol, which the layer
>> + * three protocols care about.
>> + */
>> +
>> + proto = vhdr->h_vlan_encapsulated_proto;
>> + if (ntohs(proto) >= 1536) {
>> + skb->protocol = proto;
>> + return;
>> + }
>> +
>> + rawp = skb->data;
>> + if (*(unsigned short *) rawp == 0xFFFF)
>> + /*
>> + * This is a magic hack to spot IPX packets. Older Novell
>> + * breaks the protocol design and runs IPX over 802.3 without
>> + * an 802.2 LLC layer. We look for FFFF which isn't a used
>> + * 802.2 SSAP/DSAP. This won't work for fault tolerant netware
>> + * but does for the rest.
>> + */
>> + skb->protocol = htons(ETH_P_802_3);
>> + else
>> + /*
>> + * Real 802.2 LLC
>> + */
>> + skb->protocol = htons(ETH_P_802_2);
>> +}
>
>What about doublely tagged packets?
No problem. Once they are untagged and reinjected they are untagged
again and reinjected again:
-> __netif_reveive_skb
vlan_untag
vlan_do_receive
-> __netif_receive_skb
vlan_untag
vlan_do_receive
>
>> +struct sk_buff *vlan_untag(struct sk_buff *skb)
>> +{
>> + struct vlan_hdr *vhdr;
>> + u16 vlan_tci;
>> +
>> + if (unlikely(vlan_tx_tag_present(skb))) {
>> + /* vlan_tci is already set-up so leave this for another time */
>> + return skb;
>> + }
>> +
>> + skb = skb_share_check(skb, GFP_ATOMIC);
>> + if (unlikely(!skb))
>> + goto err_free;
>> +
>> + if (unlikely(!pskb_may_pull(skb, VLAN_HLEN)))
>> + goto err_free;
>> +
>> + vhdr = (struct vlan_hdr *) skb->data;
>> + vlan_tci = ntohs(vhdr->h_vlan_TCI);
>> + __vlan_hwaccel_put_tag(skb, vlan_tci);
>> +
>> + skb_pull_rcsum(skb, VLAN_HLEN);
>> + vlan_set_encap_proto(skb, vhdr);
>> +
>> + skb = vlan_check_reorder_header(skb);
>> + if (unlikely(!skb))
>> + goto err_free;
>> +
>> + return skb;
>> +
>> +err_free:
>> + kfree_skb(skb);
>> + return NULL;
>> +}
>> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
>> index e34ea9e..b4f061f 100644
>> --- a/net/8021q/vlan_dev.c
>> +++ b/net/8021q/vlan_dev.c
>> @@ -65,179 +65,6 @@ static int vlan_dev_rebuild_header(struct sk_buff *skb)
>> return 0;
>> }
>>
>> -static inline struct sk_buff *vlan_check_reorder_header(struct sk_buff *skb)
>> -{
>> - if (vlan_dev_info(skb->dev)->flags & VLAN_FLAG_REORDER_HDR) {
>> - if (skb_cow(skb, skb_headroom(skb)) < 0)
>> - skb = NULL;
>> - if (skb) {
>> - /* Lifted from Gleb's VLAN code... */
>> - memmove(skb->data - ETH_HLEN,
>> - skb->data - VLAN_ETH_HLEN, 12);
>> - skb->mac_header += VLAN_HLEN;
>> - }
>> - }
>> -
>> - return skb;
>> -}
>> -
>> -static inline void vlan_set_encap_proto(struct sk_buff *skb,
>> - struct vlan_hdr *vhdr)
>> -{
>> - __be16 proto;
>> - unsigned char *rawp;
>> -
>> - /*
>> - * Was a VLAN packet, grab the encapsulated protocol, which the layer
>> - * three protocols care about.
>> - */
>> -
>> - proto = vhdr->h_vlan_encapsulated_proto;
>> - if (ntohs(proto) >= 1536) {
>> - skb->protocol = proto;
>> - return;
>> - }
>> -
>> - rawp = skb->data;
>> - if (*(unsigned short *)rawp == 0xFFFF)
>> - /*
>> - * This is a magic hack to spot IPX packets. Older Novell
>> - * breaks the protocol design and runs IPX over 802.3 without
>> - * an 802.2 LLC layer. We look for FFFF which isn't a used
>> - * 802.2 SSAP/DSAP. This won't work for fault tolerant netware
>> - * but does for the rest.
>> - */
>> - skb->protocol = htons(ETH_P_802_3);
>> - else
>> - /*
>> - * Real 802.2 LLC
>> - */
>> - skb->protocol = htons(ETH_P_802_2);
>> -}
>> -
>> -/*
>> - * Determine the packet's protocol ID. The rule here is that we
>> - * assume 802.3 if the type field is short enough to be a length.
>> - * This is normal practice and works for any 'now in use' protocol.
>> - *
>> - * Also, at this point we assume that we ARE dealing exclusively with
>> - * VLAN packets, or packets that should be made into VLAN packets based
>> - * on a default VLAN ID.
>> - *
>> - * NOTE: Should be similar to ethernet/eth.c.
>> - *
>> - * SANITY NOTE: This method is called when a packet is moving up the stack
>> - * towards userland. To get here, it would have already passed
>> - * through the ethernet/eth.c eth_type_trans() method.
>> - * SANITY NOTE 2: We are referencing to the VLAN_HDR frields, which MAY be
>> - * stored UNALIGNED in the memory. RISC systems don't like
>> - * such cases very much...
>> - * SANITY NOTE 2a: According to Dave Miller & Alexey, it will always be
>> - * aligned, so there doesn't need to be any of the unaligned
>> - * stuff. It has been commented out now... --Ben
>> - *
>> - */
>> -int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
>> - struct packet_type *ptype, struct net_device *orig_dev)
>> -{
>> - struct vlan_hdr *vhdr;
>> - struct vlan_pcpu_stats *rx_stats;
>> - struct net_device *vlan_dev;
>> - u16 vlan_id;
>> - u16 vlan_tci;
>> -
>> - skb = skb_share_check(skb, GFP_ATOMIC);
>> - if (skb == NULL)
>> - goto err_free;
>> -
>> - if (unlikely(!pskb_may_pull(skb, VLAN_HLEN)))
>> - goto err_free;
>> -
>> - vhdr = (struct vlan_hdr *)skb->data;
>> - vlan_tci = ntohs(vhdr->h_vlan_TCI);
>> - vlan_id = vlan_tci & VLAN_VID_MASK;
>> -
>> - rcu_read_lock();
>> - vlan_dev = vlan_find_dev(dev, vlan_id);
>> -
>> - /* If the VLAN device is defined, we use it.
>> - * If not, and the VID is 0, it is a 802.1p packet (not
>> - * really a VLAN), so we will just netif_rx it later to the
>> - * original interface, but with the skb->proto set to the
>> - * wrapped proto: we do nothing here.
>> - */
>> -
>> - if (!vlan_dev) {
>> - if (vlan_id) {
>> - pr_debug("%s: ERROR: No net_device for VID: %u on dev: %s\n",
>> - __func__, vlan_id, dev->name);
>> - goto err_unlock;
>> - }
>> - rx_stats = NULL;
>> - } else {
>> - skb->dev = vlan_dev;
>> -
>> - rx_stats = this_cpu_ptr(vlan_dev_info(skb->dev)->vlan_pcpu_stats);
>> -
>> - u64_stats_update_begin(&rx_stats->syncp);
>> - rx_stats->rx_packets++;
>> - rx_stats->rx_bytes += skb->len;
>> -
>> - skb->priority = vlan_get_ingress_priority(skb->dev, vlan_tci);
>> -
>> - pr_debug("%s: priority: %u for TCI: %hu\n",
>> - __func__, skb->priority, vlan_tci);
>> -
>> - switch (skb->pkt_type) {
>> - case PACKET_BROADCAST:
>> - /* Yeah, stats collect these together.. */
>> - /* stats->broadcast ++; // no such counter :-( */
>> - break;
>> -
>> - case PACKET_MULTICAST:
>> - rx_stats->rx_multicast++;
>> - 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,
>> - skb->dev->dev_addr))
>> - skb->pkt_type = PACKET_HOST;
>> - break;
>> - default:
>> - break;
>> - }
>> - u64_stats_update_end(&rx_stats->syncp);
>> - }
>> -
>> - skb_pull_rcsum(skb, VLAN_HLEN);
>> - vlan_set_encap_proto(skb, vhdr);
>> -
>> - if (vlan_dev) {
>> - skb = vlan_check_reorder_header(skb);
>> - if (!skb) {
>> - rx_stats->rx_errors++;
>> - goto err_unlock;
>> - }
>> - }
>> -
>> - netif_rx(skb);
>> -
>> - rcu_read_unlock();
>> - return NET_RX_SUCCESS;
>> -
>> -err_unlock:
>> - rcu_read_unlock();
>> -err_free:
>> - atomic_long_inc(&dev->rx_dropped);
>> - kfree_skb(skb);
>> - return NET_RX_DROP;
>> -}
>> -
>> static inline u16
>> vlan_dev_get_egress_qos_mask(struct net_device *dev, struct sk_buff *skb)
>> {
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 3da9fb0..bfe9fce 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -3130,6 +3130,12 @@ another_round:
>>
>> __this_cpu_inc(softnet_data.processed);
>>
>> + if (skb->protocol == cpu_to_be16(ETH_P_8021Q)) {
>> + skb = vlan_untag(skb);
>> + if (unlikely(!skb))
>> + goto out;
>> + }
>
>This becomes a NOP, why is it here?
Sorry but I probably do not understand what you mean. This piece of code
does untagging for non-hw-accel + multiply tagged frames.
>
>
>> #ifdef CONFIG_NET_CLS_ACT
>> if (skb->tc_verd & TC_NCLS) {
>> skb->tc_verd = CLR_TC_NCLS(skb->tc_verd);
>> @@ -3177,7 +3183,7 @@ ncls:
>> ret = deliver_skb(skb, pt_prev, orig_dev);
>> pt_prev = NULL;
>> }
>> - if (vlan_hwaccel_do_receive(&skb)) {
>> + if (vlan_do_receive(&skb)) {
>> ret = __netif_receive_skb(skb);
>> goto out;
>> } else if (unlikely(!skb))
>
>
>Why rename the function?
I this it is correct because this function is no longer hwaccel-specific
since non-hw-accel path is using it as well.
Regards,
Jirka
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-02 18:27 ` Jiri Pirko
@ 2011-04-03 9:27 ` Nicolas de Pesloüan
2011-04-03 13:22 ` Jiri Pirko
0 siblings, 1 reply; 20+ messages in thread
From: Nicolas de Pesloüan @ 2011-04-03 9:27 UTC (permalink / raw)
To: Jiri Pirko
Cc: Stephen Hemminger, netdev, davem, kaber, fubar, eric.dumazet,
andy, xiaosuo, jesse
Le 02/04/2011 20:27, Jiri Pirko a écrit :
> Sat, Apr 02, 2011 at 05:55:24PM CEST, shemminger@linux-foundation.org wrote:
>> On Sat, 2 Apr 2011 12:26:06 +0200
>> Jiri Pirko<jpirko@redhat.com> wrote:
<snip>
>>> + rawp = skb->data;
>>> + if (*(unsigned short *) rawp == 0xFFFF)
>>> + /*
>>> + * This is a magic hack to spot IPX packets. Older Novell
>>> + * breaks the protocol design and runs IPX over 802.3 without
>>> + * an 802.2 LLC layer. We look for FFFF which isn't a used
>>> + * 802.2 SSAP/DSAP. This won't work for fault tolerant netware
>>> + * but does for the rest.
>>> + */
>>> + skb->protocol = htons(ETH_P_802_3);
>>> + else
>>> + /*
>>> + * Real 802.2 LLC
>>> + */
>>> + skb->protocol = htons(ETH_P_802_2);
>>> +}
>>
>> What about doublely tagged packets?
>
> No problem. Once they are untagged and reinjected they are untagged
> again and reinjected again:
>
> -> __netif_reveive_skb
> vlan_untag
> vlan_do_receive
> -> __netif_receive_skb
> vlan_untag
> vlan_do_receive
Hi Jiri,
Instead of untagging and reinjecting, wouldn't it be possible to remove all 802.1Q headers in a loop
and directly deliver the untagged skb? Are there any hw-accel implementations that remove several
level of tagging?
Nicolas.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-03 9:27 ` Nicolas de Pesloüan
@ 2011-04-03 13:22 ` Jiri Pirko
0 siblings, 0 replies; 20+ messages in thread
From: Jiri Pirko @ 2011-04-03 13:22 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Stephen Hemminger, netdev, davem, kaber, fubar, eric.dumazet,
andy, xiaosuo, jesse
Sun, Apr 03, 2011 at 11:27:29AM CEST, nicolas.2p.debian@gmail.com wrote:
>Le 02/04/2011 20:27, Jiri Pirko a écrit :
>>Sat, Apr 02, 2011 at 05:55:24PM CEST, shemminger@linux-foundation.org wrote:
>>>On Sat, 2 Apr 2011 12:26:06 +0200
>>>Jiri Pirko<jpirko@redhat.com> wrote:
><snip>
>>>>+ rawp = skb->data;
>>>>+ if (*(unsigned short *) rawp == 0xFFFF)
>>>>+ /*
>>>>+ * This is a magic hack to spot IPX packets. Older Novell
>>>>+ * breaks the protocol design and runs IPX over 802.3 without
>>>>+ * an 802.2 LLC layer. We look for FFFF which isn't a used
>>>>+ * 802.2 SSAP/DSAP. This won't work for fault tolerant netware
>>>>+ * but does for the rest.
>>>>+ */
>>>>+ skb->protocol = htons(ETH_P_802_3);
>>>>+ else
>>>>+ /*
>>>>+ * Real 802.2 LLC
>>>>+ */
>>>>+ skb->protocol = htons(ETH_P_802_2);
>>>>+}
>>>
>>>What about doublely tagged packets?
>>
>>No problem. Once they are untagged and reinjected they are untagged
>>again and reinjected again:
>>
>>-> __netif_reveive_skb
>>vlan_untag
>>vlan_do_receive
>>-> __netif_receive_skb
>>vlan_untag
>>vlan_do_receive
>
>Hi Jiri,
>
>Instead of untagging and reinjecting, wouldn't it be possible to
>remove all 802.1Q headers in a loop and directly deliver the untagged
>skb? Are there any hw-accel implementations that remove several level
>of tagging?
Makes no sense to untag multiple tags in loop at once. For each tag you
need to call vlan_do_receive so the frame could be properly processed by
vlan code.
I'm not aware of a possibility of hwaccel to untag multiple tags at
once. Honestly I cannot imagine how that could be handled (maybe setting
array of vlan_tcis).
Jirka
>
> Nicolas.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-02 10:26 [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel Jiri Pirko
2011-04-02 15:55 ` Stephen Hemminger
@ 2011-04-03 15:23 ` Nicolas de Pesloüan
2011-04-03 20:38 ` Jesse Gross
1 sibling, 1 reply; 20+ messages in thread
From: Nicolas de Pesloüan @ 2011-04-03 15:23 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet, andy,
xiaosuo, jesse
Le 02/04/2011 12:26, Jiri Pirko a écrit :
> Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
> enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
> vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.
>
> For non-rx-vlan-hw-accel however, tagged skb goes thru whole
> __netif_receive_skb, it's untagged in ptype_base hander and reinjected
>
> This incosistency is fixed by this patch. Vlan untagging happens early in
> __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
> see the skb like it was untagged by hw.
>
> Signed-off-by: Jiri Pirko<jpirko@redhat.com>
<snip>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 3da9fb0..bfe9fce 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3130,6 +3130,12 @@ another_round:
>
> __this_cpu_inc(softnet_data.processed);
>
> + if (skb->protocol == cpu_to_be16(ETH_P_8021Q)) {
> + skb = vlan_untag(skb);
> + if (unlikely(!skb))
> + goto out;
> + }
> +
I like the general idea of this patch, but I don't like the idea of re-inserting specific code
inside __netif_receive_skb.
You made a great work removing most - if not all - device specific parts from __netif_receive_skb,
by introducing rx_handler.
I think the above part (and vlan_untag) should be moved to a vlan_rx_handler that would be set on
the net_devices that are the parent of a vlan net_device and are NOT hwaccel.
vlan_rx_handler would return RX_HANDLER_ANOTHER if skb holds a tagged frame (skb->dev changed) and
RX_HANDLER_PASS if skb holds an untagged frame (skb->dev unchanged).
This would also cause protocol handlers to receive the untouched (tagged) frame, if no setup
required the frame to be untagged, which I think is the right thing to do.
> @@ -3177,7 +3183,7 @@ ncls:
> ret = deliver_skb(skb, pt_prev, orig_dev);
> pt_prev = NULL;
> }
> - if (vlan_hwaccel_do_receive(&skb)) {
> + if (vlan_do_receive(&skb)) {
> ret = __netif_receive_skb(skb);
> goto out;
> } else if (unlikely(!skb))
Why are you calling __netif_receive_skb here? Can't we simply goto another_round?
I really think vlan_untag and vlan_do_receive could me merged in a vlan_rx_handler.
And if someone consider rx_handler processing happens to late for ptype_all handlers, may be it is
time to have a look at one of my previous proposed patch: http://patchwork.ozlabs.org/patch/85578/
Nicolas.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-03 15:23 ` Nicolas de Pesloüan
@ 2011-04-03 20:38 ` Jesse Gross
2011-04-04 6:54 ` Nicolas de Pesloüan
0 siblings, 1 reply; 20+ messages in thread
From: Jesse Gross @ 2011-04-03 20:38 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, netdev, davem, shemminger, kaber, fubar, eric.dumazet,
andy, xiaosuo, Eric W. Biederman
On Sun, Apr 3, 2011 at 8:23 AM, Nicolas de Pesloüan
<nicolas.2p.debian@gmail.com> wrote:
> Le 02/04/2011 12:26, Jiri Pirko a écrit :
>>
>> Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
>> enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
>> vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.
>>
>> For non-rx-vlan-hw-accel however, tagged skb goes thru whole
>> __netif_receive_skb, it's untagged in ptype_base hander and reinjected
>>
>> This incosistency is fixed by this patch. Vlan untagging happens early in
>> __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
>> see the skb like it was untagged by hw.
>>
>> Signed-off-by: Jiri Pirko<jpirko@redhat.com>
You saw Eric B.'s recent patch trying to tackle the same issues, right?:
http://permalink.gmane.org/gmane.linux.network/190229
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 3da9fb0..bfe9fce 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -3130,6 +3130,12 @@ another_round:
>>
>> __this_cpu_inc(softnet_data.processed);
>>
>> + if (skb->protocol == cpu_to_be16(ETH_P_8021Q)) {
>> + skb = vlan_untag(skb);
>> + if (unlikely(!skb))
>> + goto out;
>> + }
>> +
>
> I like the general idea of this patch, but I don't like the idea of
> re-inserting specific code inside __netif_receive_skb.
>
> You made a great work removing most - if not all - device specific parts
> from __netif_receive_skb, by introducing rx_handler.
>
> I think the above part (and vlan_untag) should be moved to a vlan_rx_handler
> that would be set on the net_devices that are the parent of a vlan
> net_device and are NOT hwaccel.
>
> vlan_rx_handler would return RX_HANDLER_ANOTHER if skb holds a tagged frame
> (skb->dev changed) and RX_HANDLER_PASS if skb holds an untagged frame
> (skb->dev unchanged).
It would be nice to merge all of this together. One complication is
the interaction of bridging and vlan on the same device. Some people
want to have a bridge for each vlan and a bridge for untagged packets.
On older kernels with vlan accelerated hardware this was possible
because vlan devices would get packets before bridging and on current
kernels it is possible with ebtables rules. If we use rx_handler for
both I believe we would need to extend it some to allow multiple
handlers.
>
> This would also cause protocol handlers to receive the untouched (tagged)
> frame, if no setup required the frame to be untagged, which I think is the
> right thing to do.
At the very least we need to make sure that these packets are marked
as PACKET_OTHERHOST because protocol handlers don't pay attention to
the vlan field.
>
>> @@ -3177,7 +3183,7 @@ ncls:
>> ret = deliver_skb(skb, pt_prev, orig_dev);
>> pt_prev = NULL;
>> }
>> - if (vlan_hwaccel_do_receive(&skb)) {
>> + if (vlan_do_receive(&skb)) {
>> ret = __netif_receive_skb(skb);
>> goto out;
>> } else if (unlikely(!skb))
>
> Why are you calling __netif_receive_skb here? Can't we simply goto
> another_round?
This code (other than the name change) predates the
another_round/rx_handler changes.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-03 20:38 ` Jesse Gross
@ 2011-04-04 6:54 ` Nicolas de Pesloüan
2011-04-04 7:14 ` Jiri Pirko
0 siblings, 1 reply; 20+ messages in thread
From: Nicolas de Pesloüan @ 2011-04-04 6:54 UTC (permalink / raw)
To: Jesse Gross
Cc: Jiri Pirko, netdev, davem, shemminger, kaber, fubar, eric.dumazet,
andy, xiaosuo, Eric W. Biederman
Le 03/04/2011 22:38, Jesse Gross a écrit :
> On Sun, Apr 3, 2011 at 8:23 AM, Nicolas de Pesloüan
> <nicolas.2p.debian@gmail.com> wrote:
>> Le 02/04/2011 12:26, Jiri Pirko a écrit :
>>>
>>> Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
>>> enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
>>> vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.
>>>
>>> For non-rx-vlan-hw-accel however, tagged skb goes thru whole
>>> __netif_receive_skb, it's untagged in ptype_base hander and reinjected
>>>
>>> This incosistency is fixed by this patch. Vlan untagging happens early in
>>> __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
>>> see the skb like it was untagged by hw.
>>>
>>> Signed-off-by: Jiri Pirko<jpirko@redhat.com>
>
> You saw Eric B.'s recent patch trying to tackle the same issues, right?:
> http://permalink.gmane.org/gmane.linux.network/190229
Yes, of course I saw it.
>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>> index 3da9fb0..bfe9fce 100644
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -3130,6 +3130,12 @@ another_round:
>>>
>>> __this_cpu_inc(softnet_data.processed);
>>>
>>> + if (skb->protocol == cpu_to_be16(ETH_P_8021Q)) {
>>> + skb = vlan_untag(skb);
>>> + if (unlikely(!skb))
>>> + goto out;
>>> + }
>>> +
>>
>> I like the general idea of this patch, but I don't like the idea of
>> re-inserting specific code inside __netif_receive_skb.
>>
>> You made a great work removing most - if not all - device specific parts
>> from __netif_receive_skb, by introducing rx_handler.
>>
>> I think the above part (and vlan_untag) should be moved to a vlan_rx_handler
>> that would be set on the net_devices that are the parent of a vlan
>> net_device and are NOT hwaccel.
>>
>> vlan_rx_handler would return RX_HANDLER_ANOTHER if skb holds a tagged frame
>> (skb->dev changed) and RX_HANDLER_PASS if skb holds an untagged frame
>> (skb->dev unchanged).
>
> It would be nice to merge all of this together. One complication is
> the interaction of bridging and vlan on the same device. Some people
> want to have a bridge for each vlan and a bridge for untagged packets.
> On older kernels with vlan accelerated hardware this was possible
> because vlan devices would get packets before bridging and on current
> kernels it is possible with ebtables rules. If we use rx_handler for
> both I believe we would need to extend it some to allow multiple
> handlers.
I totally agree.
Remember that Jiri's original proposal (last summer) was to have several rx_handlers per net_device.
I still think we need several of them, because the network stack need to be generic and allow for
any complex stacking setup. The rx_handler framework may need to be enhanced for that, but I think
it is the right tool to do all those per net_device specific features.
>> This would also cause protocol handlers to receive the untouched (tagged)
>> frame, if no setup required the frame to be untagged, which I think is the
>> right thing to do.
>
> At the very least we need to make sure that these packets are marked
> as PACKET_OTHERHOST because protocol handlers don't pay attention to
> the vlan field.
Agreed.
>>> @@ -3177,7 +3183,7 @@ ncls:
>>> ret = deliver_skb(skb, pt_prev, orig_dev);
>>> pt_prev = NULL;
>>> }
>>> - if (vlan_hwaccel_do_receive(&skb)) {
>>> + if (vlan_do_receive(&skb)) {
>>> ret = __netif_receive_skb(skb);
>>> goto out;
>>> } else if (unlikely(!skb))
>>
>> Why are you calling __netif_receive_skb here? Can't we simply goto
>> another_round?
>
> This code (other than the name change) predates the
> another_round/rx_handler changes.
Yes, you are right. Let's keep this for a possible follow-up patch, to avoid skb reinjection when it
is not strictly necessary.
Nicolas.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 6:54 ` Nicolas de Pesloüan
@ 2011-04-04 7:14 ` Jiri Pirko
2011-04-04 19:00 ` Nicolas de Pesloüan
0 siblings, 1 reply; 20+ messages in thread
From: Jiri Pirko @ 2011-04-04 7:14 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jesse Gross, netdev, davem, shemminger, kaber, fubar,
eric.dumazet, andy, xiaosuo, Eric W. Biederman
Mon, Apr 04, 2011 at 08:54:40AM CEST, nicolas.2p.debian@gmail.com wrote:
>Le 03/04/2011 22:38, Jesse Gross a écrit :
>>On Sun, Apr 3, 2011 at 8:23 AM, Nicolas de Pesloüan
>><nicolas.2p.debian@gmail.com> wrote:
>>>Le 02/04/2011 12:26, Jiri Pirko a écrit :
>>>>
>>>>Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
>>>>enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
>>>>vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.
>>>>
>>>>For non-rx-vlan-hw-accel however, tagged skb goes thru whole
>>>>__netif_receive_skb, it's untagged in ptype_base hander and reinjected
>>>>
>>>>This incosistency is fixed by this patch. Vlan untagging happens early in
>>>>__netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
>>>>see the skb like it was untagged by hw.
>>>>
>>>>Signed-off-by: Jiri Pirko<jpirko@redhat.com>
>>
>>You saw Eric B.'s recent patch trying to tackle the same issues, right?:
>>http://permalink.gmane.org/gmane.linux.network/190229
>
>Yes, of course I saw it.
I did not. Interestingly enough the patch looks pretty same as mine. I
posted rfc of my patch a while ago, before merge window. Anyway I think
my patch is nicer :)
>
>>>>diff --git a/net/core/dev.c b/net/core/dev.c
>>>>index 3da9fb0..bfe9fce 100644
>>>>--- a/net/core/dev.c
>>>>+++ b/net/core/dev.c
>>>>@@ -3130,6 +3130,12 @@ another_round:
>>>>
>>>> __this_cpu_inc(softnet_data.processed);
>>>>
>>>>+ if (skb->protocol == cpu_to_be16(ETH_P_8021Q)) {
>>>>+ skb = vlan_untag(skb);
>>>>+ if (unlikely(!skb))
>>>>+ goto out;
>>>>+ }
>>>>+
>>>
>>>I like the general idea of this patch, but I don't like the idea of
>>>re-inserting specific code inside __netif_receive_skb.
>>>
>>>You made a great work removing most - if not all - device specific parts
>>>from __netif_receive_skb, by introducing rx_handler.
>>>
>>>I think the above part (and vlan_untag) should be moved to a vlan_rx_handler
>>>that would be set on the net_devices that are the parent of a vlan
>>>net_device and are NOT hwaccel.
>>>
>>>vlan_rx_handler would return RX_HANDLER_ANOTHER if skb holds a tagged frame
>>>(skb->dev changed) and RX_HANDLER_PASS if skb holds an untagged frame
>>>(skb->dev unchanged).
>>
>>It would be nice to merge all of this together. One complication is
>>the interaction of bridging and vlan on the same device. Some people
>>want to have a bridge for each vlan and a bridge for untagged packets.
>> On older kernels with vlan accelerated hardware this was possible
>>because vlan devices would get packets before bridging and on current
>>kernels it is possible with ebtables rules. If we use rx_handler for
>>both I believe we would need to extend it some to allow multiple
>>handlers.
>
>I totally agree.
I do not. The reason I do vlan_untag early is so actually emulates
hw acceleration. The reason is to make rx path of hwaccel an
nonhwaccel similar. If you move vlan untag to rx_handler, this goal
wouldn't be achieved.
>
>Remember that Jiri's original proposal (last summer) was to have
>several rx_handlers per net_device. I still think we need several of
>them, because the network stack need to be generic and allow for any
>complex stacking setup. The rx_handler framework may need to be
>enhanced for that, but I think it is the right tool to do all those
>per net_device specific features.
>
>>>This would also cause protocol handlers to receive the untouched (tagged)
>>>frame, if no setup required the frame to be untagged, which I think is the
>>>right thing to do.
>>
>>At the very least we need to make sure that these packets are marked
>>as PACKET_OTHERHOST because protocol handlers don't pay attention to
>>the vlan field.
>
>Agreed.
>
>>>>@@ -3177,7 +3183,7 @@ ncls:
>>>> ret = deliver_skb(skb, pt_prev, orig_dev);
>>>> pt_prev = NULL;
>>>> }
>>>>- if (vlan_hwaccel_do_receive(&skb)) {
>>>>+ if (vlan_do_receive(&skb)) {
>>>> ret = __netif_receive_skb(skb);
>>>> goto out;
>>>> } else if (unlikely(!skb))
>>>
>>>Why are you calling __netif_receive_skb here? Can't we simply goto
>>>another_round?
>>
>>This code (other than the name change) predates the
>>another_round/rx_handler changes.
>
>Yes, you are right. Let's keep this for a possible follow-up patch,
>to avoid skb reinjection when it is not strictly necessary.
To do another round here was my attention do do in follow up patch (I'm
still figuring out how to move this effectively into rx_handlers)
>
> Nicolas.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 7:14 ` Jiri Pirko
@ 2011-04-04 19:00 ` Nicolas de Pesloüan
2011-04-04 19:51 ` Eric W. Biederman
2011-04-04 20:30 ` Jiri Pirko
0 siblings, 2 replies; 20+ messages in thread
From: Nicolas de Pesloüan @ 2011-04-04 19:00 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jesse Gross, netdev, davem, shemminger, kaber, fubar,
eric.dumazet, andy, xiaosuo, Eric W. Biederman
Le 04/04/2011 09:14, Jiri Pirko a écrit :
> Mon, Apr 04, 2011 at 08:54:40AM CEST, nicolas.2p.debian@gmail.com wrote:
>> Le 03/04/2011 22:38, Jesse Gross a écrit :
<snip>
>>> It would be nice to merge all of this together. One complication is
>>> the interaction of bridging and vlan on the same device. Some people
>>> want to have a bridge for each vlan and a bridge for untagged packets.
>>> On older kernels with vlan accelerated hardware this was possible
>>> because vlan devices would get packets before bridging and on current
>>> kernels it is possible with ebtables rules. If we use rx_handler for
>>> both I believe we would need to extend it some to allow multiple
>>> handlers.
>>
>> I totally agree.
>
> I do not. The reason I do vlan_untag early is so actually emulates
> hw acceleration. The reason is to make rx path of hwaccel an
> nonhwaccel similar. If you move vlan untag to rx_handler, this goal
> wouldn't be achieved.
Need to think more about that point.
>> Remember that Jiri's original proposal (last summer) was to have
>> several rx_handlers per net_device. I still think we need several of
>> them, because the network stack need to be generic and allow for any
>> complex stacking setup. The rx_handler framework may need to be
>> enhanced for that, but I think it is the right tool to do all those
>> per net_device specific features.
>>
>>>> This would also cause protocol handlers to receive the untouched (tagged)
>>>> frame, if no setup required the frame to be untagged, which I think is the
>>>> right thing to do.
>>>
>>> At the very least we need to make sure that these packets are marked
>>> as PACKET_OTHERHOST because protocol handlers don't pay attention to
>>> the vlan field.
>>
>> Agreed.
>>
>>>>> @@ -3177,7 +3183,7 @@ ncls:
>>>>> ret = deliver_skb(skb, pt_prev, orig_dev);
>>>>> pt_prev = NULL;
>>>>> }
>>>>> - if (vlan_hwaccel_do_receive(&skb)) {
>>>>> + if (vlan_do_receive(&skb)) {
>>>>> ret = __netif_receive_skb(skb);
>>>>> goto out;
>>>>> } else if (unlikely(!skb))
>>>>
>>>> Why are you calling __netif_receive_skb here? Can't we simply goto
>>>> another_round?
>>>
>>> This code (other than the name change) predates the
>>> another_round/rx_handler changes.
>>
>> Yes, you are right. Let's keep this for a possible follow-up patch,
>> to avoid skb reinjection when it is not strictly necessary.
>
> To do another round here was my attention do do in follow up patch (I'm
> still figuring out how to move this effectively into rx_handlers)
So you want to move vlan_do_receive into an rx_handler, but want untagging to stay hard-coded at the
beginning of __netif_receive_skb. I don't think I understand the rational behind that.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 19:00 ` Nicolas de Pesloüan
@ 2011-04-04 19:51 ` Eric W. Biederman
2011-04-04 20:29 ` Jiri Pirko
2011-04-04 20:47 ` Nicolas de Pesloüan
2011-04-04 20:30 ` Jiri Pirko
1 sibling, 2 replies; 20+ messages in thread
From: Eric W. Biederman @ 2011-04-04 19:51 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, Jesse Gross, netdev, davem, shemminger, kaber, fubar,
eric.dumazet, andy, xiaosuo
Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> writes:
> Le 04/04/2011 09:14, Jiri Pirko a écrit :
>> Mon, Apr 04, 2011 at 08:54:40AM CEST, nicolas.2p.debian@gmail.com wrote:
>>> Le 03/04/2011 22:38, Jesse Gross a écrit :
> <snip>
>>>> It would be nice to merge all of this together. One complication is
>>>> the interaction of bridging and vlan on the same device. Some people
>>>> want to have a bridge for each vlan and a bridge for untagged packets.
>>>> On older kernels with vlan accelerated hardware this was possible
>>>> because vlan devices would get packets before bridging and on current
>>>> kernels it is possible with ebtables rules. If we use rx_handler for
>>>> both I believe we would need to extend it some to allow multiple
>>>> handlers.
>>>
>>> I totally agree.
>>
>> I do not. The reason I do vlan_untag early is so actually emulates
>> hw acceleration. The reason is to make rx path of hwaccel an
>> nonhwaccel similar. If you move vlan untag to rx_handler, this goal
>> wouldn't be achieved.
>
> Need to think more about that point.
>
>>> Remember that Jiri's original proposal (last summer) was to have
>>> several rx_handlers per net_device. I still think we need several of
>>> them, because the network stack need to be generic and allow for any
>>> complex stacking setup. The rx_handler framework may need to be
>>> enhanced for that, but I think it is the right tool to do all those
>>> per net_device specific features.
>>>
>>>>> This would also cause protocol handlers to receive the untouched (tagged)
>>>>> frame, if no setup required the frame to be untagged, which I think is the
>>>>> right thing to do.
>>>>
>>>> At the very least we need to make sure that these packets are marked
>>>> as PACKET_OTHERHOST because protocol handlers don't pay attention to
>>>> the vlan field.
>>>
>>> Agreed.
>>>
>>>>>> @@ -3177,7 +3183,7 @@ ncls:
>>>>>> ret = deliver_skb(skb, pt_prev, orig_dev);
>>>>>> pt_prev = NULL;
>>>>>> }
>>>>>> - if (vlan_hwaccel_do_receive(&skb)) {
>>>>>> + if (vlan_do_receive(&skb)) {
>>>>>> ret = __netif_receive_skb(skb);
>>>>>> goto out;
>>>>>> } else if (unlikely(!skb))
>>>>>
>>>>> Why are you calling __netif_receive_skb here? Can't we simply goto
>>>>> another_round?
>>>>
>>>> This code (other than the name change) predates the
>>>> another_round/rx_handler changes.
>>>
>>> Yes, you are right. Let's keep this for a possible follow-up patch,
>>> to avoid skb reinjection when it is not strictly necessary.
>>
>> To do another round here was my attention do do in follow up patch (I'm
>> still figuring out how to move this effectively into rx_handlers)
>
> So you want to move vlan_do_receive into an rx_handler, but want untagging to
> stay hard-coded at the beginning of __netif_receive_skb. I don't think I
> understand the rational behind that.
__netif_receive_skb is actually late for untagging. eth_type_trans
would be better but not path of control into __netif_receive_skb
actually calls eth_type_trans.
Eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 19:51 ` Eric W. Biederman
@ 2011-04-04 20:29 ` Jiri Pirko
2011-04-04 20:47 ` Nicolas de Pesloüan
1 sibling, 0 replies; 20+ messages in thread
From: Jiri Pirko @ 2011-04-04 20:29 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Nicolas de Pesloüan, Jesse Gross, netdev, davem, shemminger,
kaber, fubar, eric.dumazet, andy, xiaosuo
Mon, Apr 04, 2011 at 09:51:51PM CEST, ebiederm@xmission.com wrote:
>Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> writes:
>
>> Le 04/04/2011 09:14, Jiri Pirko a écrit :
>>> Mon, Apr 04, 2011 at 08:54:40AM CEST, nicolas.2p.debian@gmail.com wrote:
>>>> Le 03/04/2011 22:38, Jesse Gross a écrit :
>> <snip>
>>>>> It would be nice to merge all of this together. One complication is
>>>>> the interaction of bridging and vlan on the same device. Some people
>>>>> want to have a bridge for each vlan and a bridge for untagged packets.
>>>>> On older kernels with vlan accelerated hardware this was possible
>>>>> because vlan devices would get packets before bridging and on current
>>>>> kernels it is possible with ebtables rules. If we use rx_handler for
>>>>> both I believe we would need to extend it some to allow multiple
>>>>> handlers.
>>>>
>>>> I totally agree.
>>>
>>> I do not. The reason I do vlan_untag early is so actually emulates
>>> hw acceleration. The reason is to make rx path of hwaccel an
>>> nonhwaccel similar. If you move vlan untag to rx_handler, this goal
>>> wouldn't be achieved.
>>
>> Need to think more about that point.
>>
>>>> Remember that Jiri's original proposal (last summer) was to have
>>>> several rx_handlers per net_device. I still think we need several of
>>>> them, because the network stack need to be generic and allow for any
>>>> complex stacking setup. The rx_handler framework may need to be
>>>> enhanced for that, but I think it is the right tool to do all those
>>>> per net_device specific features.
>>>>
>>>>>> This would also cause protocol handlers to receive the untouched (tagged)
>>>>>> frame, if no setup required the frame to be untagged, which I think is the
>>>>>> right thing to do.
>>>>>
>>>>> At the very least we need to make sure that these packets are marked
>>>>> as PACKET_OTHERHOST because protocol handlers don't pay attention to
>>>>> the vlan field.
>>>>
>>>> Agreed.
>>>>
>>>>>>> @@ -3177,7 +3183,7 @@ ncls:
>>>>>>> ret = deliver_skb(skb, pt_prev, orig_dev);
>>>>>>> pt_prev = NULL;
>>>>>>> }
>>>>>>> - if (vlan_hwaccel_do_receive(&skb)) {
>>>>>>> + if (vlan_do_receive(&skb)) {
>>>>>>> ret = __netif_receive_skb(skb);
>>>>>>> goto out;
>>>>>>> } else if (unlikely(!skb))
>>>>>>
>>>>>> Why are you calling __netif_receive_skb here? Can't we simply goto
>>>>>> another_round?
>>>>>
>>>>> This code (other than the name change) predates the
>>>>> another_round/rx_handler changes.
>>>>
>>>> Yes, you are right. Let's keep this for a possible follow-up patch,
>>>> to avoid skb reinjection when it is not strictly necessary.
>>>
>>> To do another round here was my attention do do in follow up patch (I'm
>>> still figuring out how to move this effectively into rx_handlers)
>>
>> So you want to move vlan_do_receive into an rx_handler, but want untagging to
>> stay hard-coded at the beginning of __netif_receive_skb. I don't think I
>> understand the rational behind that.
>
>__netif_receive_skb is actually late for untagging. eth_type_trans
>would be better but not path of control into __netif_receive_skb
>actually calls eth_type_trans.
Why __netif_receive_skb is late?
>
>Eric
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 19:51 ` Eric W. Biederman
2011-04-04 20:29 ` Jiri Pirko
@ 2011-04-04 20:47 ` Nicolas de Pesloüan
2011-04-04 20:50 ` Jesse Gross
2011-04-05 7:26 ` Jiri Pirko
1 sibling, 2 replies; 20+ messages in thread
From: Nicolas de Pesloüan @ 2011-04-04 20:47 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Jiri Pirko, Jesse Gross, netdev, davem, shemminger, kaber, fubar,
eric.dumazet, andy, xiaosuo
Le 04/04/2011 21:51, Eric W. Biederman a écrit :
>
> __netif_receive_skb is actually late for untagging. eth_type_trans
> would be better but not path of control into __netif_receive_skb
> actually calls eth_type_trans.
Because vlan may nest, we need to keep some sort of frame untagging inside __netif_receive_skb.
In order to avoid duplicate code, I suggest to manage the first level untagging (for non hwaccel)
the same way we manage other levels of untagging (which are by design non hwaccell).
Hence my proposal to use a rx_handler on the parent device of the vlan device, if we know the parent
device lack hwaccel vlan handling.
So, instead of trying to mimic the hwaccel path in software, I suggest to simply disable software
untagging when we know hwaccel untagging is present, by removing (or not installing) the vlan
rx_handler from the hwaccel net_device.
Can someone clarify whether hwaccel capable NIC will always untag tagged frames or will only do so
if requested at device setup?
Nicolas.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 20:47 ` Nicolas de Pesloüan
@ 2011-04-04 20:50 ` Jesse Gross
2011-04-04 21:04 ` Nicolas de Pesloüan
2011-04-05 7:26 ` Jiri Pirko
1 sibling, 1 reply; 20+ messages in thread
From: Jesse Gross @ 2011-04-04 20:50 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Eric W. Biederman, Jiri Pirko, netdev, davem, shemminger, kaber,
fubar, eric.dumazet, andy, xiaosuo
On Mon, Apr 4, 2011 at 1:47 PM, Nicolas de Pesloüan
<nicolas.2p.debian@gmail.com> wrote:
> Can someone clarify whether hwaccel capable NIC will always untag tagged
> frames or will only do so if requested at device setup?
It can be changed on the fly by ethtool, similar to other forms of offloading.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 20:50 ` Jesse Gross
@ 2011-04-04 21:04 ` Nicolas de Pesloüan
2011-04-05 7:25 ` Jiri Pirko
0 siblings, 1 reply; 20+ messages in thread
From: Nicolas de Pesloüan @ 2011-04-04 21:04 UTC (permalink / raw)
To: Jesse Gross
Cc: Eric W. Biederman, Jiri Pirko, netdev, davem, shemminger, kaber,
fubar, eric.dumazet, andy, xiaosuo
Le 04/04/2011 22:50, Jesse Gross a écrit :
> On Mon, Apr 4, 2011 at 1:47 PM, Nicolas de Pesloüan
> <nicolas.2p.debian@gmail.com> wrote:
>> Can someone clarify whether hwaccel capable NIC will always untag tagged
>> frames or will only do so if requested at device setup?
>
> It can be changed on the fly by ethtool, similar to other forms of offloading.
Thanks Jesse.
So if hwaccell vlan untagging is disabled, what is the current behavior? Is the frame delivered
untouched (tagged) to ptype_all handlers if no particular vlan device is setup on the parent device?
With Jiri's patch, it would be always untagged, whatever requested by ethtool.
Am I right?
Nicolas.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 21:04 ` Nicolas de Pesloüan
@ 2011-04-05 7:25 ` Jiri Pirko
0 siblings, 0 replies; 20+ messages in thread
From: Jiri Pirko @ 2011-04-05 7:25 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jesse Gross, Eric W. Biederman, netdev, davem, shemminger, kaber,
fubar, eric.dumazet, andy, xiaosuo
Mon, Apr 04, 2011 at 11:04:09PM CEST, nicolas.2p.debian@gmail.com wrote:
>Le 04/04/2011 22:50, Jesse Gross a écrit :
>>On Mon, Apr 4, 2011 at 1:47 PM, Nicolas de Pesloüan
>><nicolas.2p.debian@gmail.com> wrote:
>>>Can someone clarify whether hwaccel capable NIC will always untag tagged
>>>frames or will only do so if requested at device setup?
>>
>>It can be changed on the fly by ethtool, similar to other forms of offloading.
>
>Thanks Jesse.
>
>So if hwaccell vlan untagging is disabled, what is the current
>behavior? Is the frame delivered untouched (tagged) to ptype_all
>handlers if no particular vlan device is setup on the parent device?
Even if vlan device is setup on the parent device.
>
>With Jiri's patch, it would be always untagged, whatever requested by ethtool.
Correct. That's more or less purpose of the patch.
>
>Am I right?
>
> Nicolas.
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 20:47 ` Nicolas de Pesloüan
2011-04-04 20:50 ` Jesse Gross
@ 2011-04-05 7:26 ` Jiri Pirko
1 sibling, 0 replies; 20+ messages in thread
From: Jiri Pirko @ 2011-04-05 7:26 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Eric W. Biederman, Jesse Gross, netdev, davem, shemminger, kaber,
fubar, eric.dumazet, andy, xiaosuo
Mon, Apr 04, 2011 at 10:47:48PM CEST, nicolas.2p.debian@gmail.com wrote:
>Le 04/04/2011 21:51, Eric W. Biederman a écrit :
>
>>
>>__netif_receive_skb is actually late for untagging. eth_type_trans
>>would be better but not path of control into __netif_receive_skb
>>actually calls eth_type_trans.
>
>Because vlan may nest, we need to keep some sort of frame untagging inside __netif_receive_skb.
You are correct here. It needs to stay inside __netif_receive_skb
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 19:00 ` Nicolas de Pesloüan
2011-04-04 19:51 ` Eric W. Biederman
@ 2011-04-04 20:30 ` Jiri Pirko
2011-04-04 20:51 ` Nicolas de Pesloüan
1 sibling, 1 reply; 20+ messages in thread
From: Jiri Pirko @ 2011-04-04 20:30 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jesse Gross, netdev, davem, shemminger, kaber, fubar,
eric.dumazet, andy, xiaosuo, Eric W. Biederman
Mon, Apr 04, 2011 at 09:00:00PM CEST, nicolas.2p.debian@gmail.com wrote:
>Le 04/04/2011 09:14, Jiri Pirko a écrit :
>>Mon, Apr 04, 2011 at 08:54:40AM CEST, nicolas.2p.debian@gmail.com wrote:
>>>Le 03/04/2011 22:38, Jesse Gross a écrit :
><snip>
>>>>It would be nice to merge all of this together. One complication is
>>>>the interaction of bridging and vlan on the same device. Some people
>>>>want to have a bridge for each vlan and a bridge for untagged packets.
>>>> On older kernels with vlan accelerated hardware this was possible
>>>>because vlan devices would get packets before bridging and on current
>>>>kernels it is possible with ebtables rules. If we use rx_handler for
>>>>both I believe we would need to extend it some to allow multiple
>>>>handlers.
>>>
>>>I totally agree.
>>
>>I do not. The reason I do vlan_untag early is so actually emulates
>>hw acceleration. The reason is to make rx path of hwaccel an
>>nonhwaccel similar. If you move vlan untag to rx_handler, this goal
>>wouldn't be achieved.
>
>Need to think more about that point.
>
>>>Remember that Jiri's original proposal (last summer) was to have
>>>several rx_handlers per net_device. I still think we need several of
>>>them, because the network stack need to be generic and allow for any
>>>complex stacking setup. The rx_handler framework may need to be
>>>enhanced for that, but I think it is the right tool to do all those
>>>per net_device specific features.
>>>
>>>>>This would also cause protocol handlers to receive the untouched (tagged)
>>>>>frame, if no setup required the frame to be untagged, which I think is the
>>>>>right thing to do.
>>>>
>>>>At the very least we need to make sure that these packets are marked
>>>>as PACKET_OTHERHOST because protocol handlers don't pay attention to
>>>>the vlan field.
>>>
>>>Agreed.
>>>
>>>>>>@@ -3177,7 +3183,7 @@ ncls:
>>>>>> ret = deliver_skb(skb, pt_prev, orig_dev);
>>>>>> pt_prev = NULL;
>>>>>> }
>>>>>>- if (vlan_hwaccel_do_receive(&skb)) {
>>>>>>+ if (vlan_do_receive(&skb)) {
>>>>>> ret = __netif_receive_skb(skb);
>>>>>> goto out;
>>>>>> } else if (unlikely(!skb))
>>>>>
>>>>>Why are you calling __netif_receive_skb here? Can't we simply goto
>>>>>another_round?
>>>>
>>>>This code (other than the name change) predates the
>>>>another_round/rx_handler changes.
>>>
>>>Yes, you are right. Let's keep this for a possible follow-up patch,
>>>to avoid skb reinjection when it is not strictly necessary.
>>
>>To do another round here was my attention do do in follow up patch (I'm
>>still figuring out how to move this effectively into rx_handlers)
>
>So you want to move vlan_do_receive into an rx_handler, but want
>untagging to stay hard-coded at the beginning of __netif_receive_skb.
>I don't think I understand the rational behind that.
vlan_hwaccel_do_receive/vlan_do_receive could be converted to
rx_handler, not untagging.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 20:30 ` Jiri Pirko
@ 2011-04-04 20:51 ` Nicolas de Pesloüan
2011-04-05 7:19 ` Jiri Pirko
0 siblings, 1 reply; 20+ messages in thread
From: Nicolas de Pesloüan @ 2011-04-04 20:51 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jesse Gross, netdev, davem, shemminger, kaber, fubar,
eric.dumazet, andy, xiaosuo, Eric W. Biederman
Le 04/04/2011 22:30, Jiri Pirko a écrit :
> Mon, Apr 04, 2011 at 09:00:00PM CEST, nicolas.2p.debian@gmail.com wrote:
>> Le 04/04/2011 09:14, Jiri Pirko a écrit :
<snip>
>> So you want to move vlan_do_receive into an rx_handler, but want
>> untagging to stay hard-coded at the beginning of __netif_receive_skb.
>> I don't think I understand the rational behind that.
>
> vlan_hwaccel_do_receive/vlan_do_receive could be converted to
> rx_handler, not untagging.
Why do you consider untagging cannot be converted to rx_handler?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
2011-04-04 20:51 ` Nicolas de Pesloüan
@ 2011-04-05 7:19 ` Jiri Pirko
0 siblings, 0 replies; 20+ messages in thread
From: Jiri Pirko @ 2011-04-05 7:19 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jesse Gross, netdev, davem, shemminger, kaber, fubar,
eric.dumazet, andy, xiaosuo, Eric W. Biederman
Mon, Apr 04, 2011 at 10:51:25PM CEST, nicolas.2p.debian@gmail.com wrote:
>Le 04/04/2011 22:30, Jiri Pirko a écrit :
>>Mon, Apr 04, 2011 at 09:00:00PM CEST, nicolas.2p.debian@gmail.com wrote:
>>>Le 04/04/2011 09:14, Jiri Pirko a écrit :
><snip>
>>>So you want to move vlan_do_receive into an rx_handler, but want
>>>untagging to stay hard-coded at the beginning of __netif_receive_skb.
>>>I don't think I understand the rational behind that.
>>
>>vlan_hwaccel_do_receive/vlan_do_receive could be converted to
>>rx_handler, not untagging.
>
>Why do you consider untagging cannot be converted to rx_handler?
I already told you that the reason ot the patch is to unify hwaccel path
and nonhwaccel path. When you do untag in rx_handler, that's too late.
Paths would be still different.
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2011-04-05 7:27 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-02 10:26 [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel Jiri Pirko
2011-04-02 15:55 ` Stephen Hemminger
2011-04-02 18:27 ` Jiri Pirko
2011-04-03 9:27 ` Nicolas de Pesloüan
2011-04-03 13:22 ` Jiri Pirko
2011-04-03 15:23 ` Nicolas de Pesloüan
2011-04-03 20:38 ` Jesse Gross
2011-04-04 6:54 ` Nicolas de Pesloüan
2011-04-04 7:14 ` Jiri Pirko
2011-04-04 19:00 ` Nicolas de Pesloüan
2011-04-04 19:51 ` Eric W. Biederman
2011-04-04 20:29 ` Jiri Pirko
2011-04-04 20:47 ` Nicolas de Pesloüan
2011-04-04 20:50 ` Jesse Gross
2011-04-04 21:04 ` Nicolas de Pesloüan
2011-04-05 7:25 ` Jiri Pirko
2011-04-05 7:26 ` Jiri Pirko
2011-04-04 20:30 ` Jiri Pirko
2011-04-04 20:51 ` Nicolas de Pesloüan
2011-04-05 7:19 ` Jiri Pirko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).