login
Login / Register
Header Space

 
 

Home » Mailing list archives » linux-netdev » 2008 » April » 11

Re: Re-queueing of skb in vlan_skb_recv

Previous thread: [PATCH][NET_SCHED] cls_u32: refcounting fix for u32_delete() by Jarek Poplawski on Friday, April 11, 2008 - 8:45 am. (8 messages)

Next thread: [PATCH] nfsroot: fix typo by Peter Korsgaard on Friday, April 11, 2008 - 9:44 am. (1 message)
[view original message]
From: Patrick McHardy <kaber@...>
To: Brian Oostenbrink <Brian_Oostenbrink@...>
Cc: <linux-net@...>, Linux Netdev List <netdev@...>
Subject: Re: Re-queueing of skb in vlan_skb_recv
Date: Friday, April 11, 2008 - 8:46 am

Its done to save stack space. There's currently a discussion
about making loopback use netif_receive_skb in case enough
stack is still available. Once that patch gets merged I'll
change VLAN in a similar way.

--
[view original message]
From: Al Viro <viro@...>
To: Patrick McHardy <kaber@...>
Cc: Brian Oostenbrink <Brian_Oostenbrink@...>, <linux-net@...>, Linux Netdev List <netdev@...>
Subject: Re: Re-queueing of skb in vlan_skb_recv
Date: Friday, April 11, 2008 - 8:53 am

Another possibility would be to allow -&gt;func() of packet_type to return an
skb for reprocessing...
--
[view original message]
From: Patrick McHardy <kaber@...>
To: Al Viro <viro@...>
Cc: Brian Oostenbrink <Brian_Oostenbrink@...>, <linux-net@...>, Linux Netdev List <netdev@...>
Subject: Re: Re-queueing of skb in vlan_skb_recv
Date: Friday, April 11, 2008 - 9:02 am

That should work fine for VLAN, but not for loopback since its
called on the TX path. I think I prefer Eric's suggested way
because it doesn't require to change all the other existing
packet_type users.

--
[view original message]
From: David Miller <davem@...>
To: <kaber@...>
Cc: <viro@...>, <Brian_Oostenbrink@...>, <linux-net@...>, <netdev@...>
Subject: Re: Re-queueing of skb in vlan_skb_recv
Date: Friday, April 11, 2008 - 1:54 pm

From: Patrick McHardy &lt;kaber@trash.net&gt;

I think Al's idea is the most elegant proposed so far and we could do
something similar on the TX side as well.

Yes, it means diddling with a lot of call sites, but we do that all
the time and it's heaps better then these "check the stack space
remaining" hacks being proposed.
--
[view original message]
From: Patrick McHardy <kaber@...>
To: David Miller <davem@...>
Cc: <viro@...>, <Brian_Oostenbrink@...>, <linux-net@...>, <netdev@...>
Subject: Re: Re-queueing of skb in vlan_skb_recv
Date: Sunday, April 13, 2008 - 12:47 am

Agreed on second thought, I guess I was just being lazy :)


--
[view original message]
From: Jeremy Jackson <jerj@...>
To: Patrick McHardy <kaber@...>
Cc: Brian Oostenbrink <Brian_Oostenbrink@...>, <linux-net@...>, Linux Netdev List <netdev@...>
Subject: Re: Re-queueing of skb in vlan_skb_recv
Date: Friday, April 11, 2008 - 8:53 am

There was a patch floating around fixing VLAN + Bridge, I'm wondering if
it got any traction (ie merged), or if this would affect future merge of
that feature?


-- 
Jeremy Jackson
Coplanar Networks
(519)489-4903
http://www.coplanar.net
jerj@coplanar.net

--
[view original message]
From: Patrick McHardy <kaber@...>
To: Jeremy Jackson <jerj@...>
Cc: Brian Oostenbrink <Brian_Oostenbrink@...>, <linux-net@...>, Linux Netdev List <netdev@...>
Subject: Re: Re-queueing of skb in vlan_skb_recv
Date: Friday, April 11, 2008 - 9:02 am

Whats broken with VLAN + Bridge? Do you have a pointer to
this patch?
--
[view original message]
From: Stephen Hemminger <shemminger@...>
To: Patrick McHardy <kaber@...>
Cc: Jeremy Jackson <jerj@...>, Brian Oostenbrink <Brian_Oostenbrink@...>, <linux-net@...>, Linux Netdev List <netdev@...>
Subject: Re: Re-queueing of skb in vlan_skb_recv
Date: Friday, April 11, 2008 - 11:44 am

On Fri, 11 Apr 2008 15:02:39 +0200

This is sitting in my to be examined queue...

Subject: Re: [Bridge] [PATCH] Add vlan id to bridge forward database
Message-ID: &lt;20080402093004.GA13430@localhost&gt;
References: &lt;4766a3d1.02ab100a.0be8.6fdc@mx.google.com&gt; &lt;20071217085349.729e5c17@deepthought&gt; &lt;20080128153914.GA5880@localhost&gt; &lt;20080317113537.496d9347@extreme&gt;
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: &lt;20080317113537.496d9347@extreme&gt;
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
Received-SPF: pass (domain of jaime.medrano@gmail.com designates 209.85.134.190 as permitted sender)
X-Spam-Status: No, hits=-6.312 required=5 tests=BAYES_00,OSDL_HEADER_SUBJECT_BRACKETED,PATCH_SUBJECT_OSDL
X-Spam-Checker-Version: SpamAssassin 3.2.4-osdl_revision__1.47__
X-MIMEDefang-Filter: lf$Revision: 1.188 $
X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13





It will work with drivers with hardware accel VLAN receive support if no
vlan device is attached to the network device of one of the ports of the
bridge. It will also work if a vlan device is attached to the bridge
device. In those cases, hw accel is not used.

However, it won't work if a vlan device is attached to the network
device of one of the ports. Hw accel will be used and the vlan tag won't
be available. Anyway, this is a bad idea since normal bridging won't work
either. The vlan won't be regenerated at bridge output since current
bridge code doesn't get that tag.

If the vlan device is attached to the bridge device then bridging has no
problems as hw accel receiving is not used.

The patch has also been generalized to support any number of vlan nested
tags. Vlan tag recording can be disabled at all if BR_MAX_VLAN_TAGS is
set to 0.

---
Subject: [PATCH] Add vlan tags to bridge forward database

This makes forwarding table aware of 802.1Q vlan tags and stores
vlan ids with MACs in the table.

It solves problems when having same MAC o...
[ message continues ]
[view original message]
From: Patrick McHardy <kaber@...>
To: Stephen Hemminger <shemminger@...>
Cc: Jeremy Jackson <jerj@...>, Brian Oostenbrink <Brian_Oostenbrink@...>, <linux-net@...>, Linux Netdev List <netdev@...>
Subject: Re: Re-queueing of skb in vlan_skb_recv
Date: Friday, April 11, 2008 - 12:16 pm

Thanks for the pointer, I'll try to have a closer look this weekend.
--
Previous thread: [PATCH][NET_SCHED] cls_u32: refcounting fix for u32_delete() by Jarek Poplawski on Friday, April 11, 2008 - 8:45 am. (8 messages)

Next thread: [PATCH] nfsroot: fix typo by Peter Korsgaard on Friday, April 11, 2008 - 9:44 am. (1 message)

Mail archive search
Enter your search terms.
Optionally limit your search to a specific mailing list.
advanced
Recent Tags
more tags
Colocation donated by:
Who's online
There are currently 2 users and 1199 guests online.

Online users

Syndicate
Syndicate content
© 2007 KernelTrap.  |  Powered by Drupal.  |  Legal statement.
speck-geostationary