* Re: [PATCH] netns: add /proc/*/net/id symlink
From: Eric W. Biederman @ 2011-05-22 0:15 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: davem, netdev, equinox, Linux Containers
In-Reply-To: <20110521223054.GA3198@p183>
Adding the containers list.
Alexey Dobriyan <adobriyan@gmail.com> writes:
> On Sat, May 21, 2011 at 08:39:37AM -0700, Eric W. Biederman wrote:
>> Alexey Dobriyan <adobriyan@gmail.com> writes:
>> > * init_net always has id 0
>> > * two netns do not have same id
>> > * id is unsigned integer
>>
>> I don't like this patch because we already have a proc interface
>> that already solves this in production kernels today.
>>
>> - stat is a single syscall
>> - two netns do not have the same id
>> - id is an ino_t.
>
> Yeah, stat /proc/*/net/dev works.
> If you document this, it means we can't change the way ->low_ino is set.
> And we can't do other things inside irregular part of procfs.
Maybe. Certainly there are things that would suggest we need some
fixes to this part of procfs.
> But can we add clean interface once in a while.
I am all for making a clean solution. I don't see a proc file
in in /proc/net that provides a small integer as particularly clean.
It has the classic problem of what namespace are namespaces named in.
It only solves the problem for the network namespace.
So on that level I really like the idea of inode numbers in proc
being the place where we have a name. People generally don't get
confused about inode numbers understanding they are an implementation
detail but they do understand that inode numbers plus filesystem
information can be used to compare files for identity.
So let's skip the fact that /proc/*/net/dev happens to work for a
moment.
For clean interfaces I am in the process of adding /proc/<pid>/ns/net,
/proc/<pid>/ns/ipc, and /proc/<pid>/ns/uts.
If we can make those files inode number be the same if the namespace is
the same like /proc/<pid>/net/dev is today. I think we will have a
clean solution.
Additionally that solution will work for comparing network namespaces
that don't happen to have any processes in them at the moment. Because
fstat works on file descriptors.
With the /proc/<pid>/ns/net file and bind mounts I have solved the
deeper problem of how do we get userspace policy into the naming of
namespaces. With those files and the setns system call I have solved
the other problem of what is a good way to refer to namespaces without
assuming a global name. So once those changes are merged I expect there
to be much less pressure to misuse any kind of identifier we can have.
And if we only make the guarantee about inode consistency for the
/proc/<pid>/ns/FILE files I don't expect it will make maintenance
of procfs any harder than it already is.
Eric
^ permalink raw reply
* Re: [GIT PULL] Namespace file descriptors for 2.6.40
From: Eric W. Biederman @ 2011-05-22 0:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Linux Containers, netdev, James Bottomley,
Geert Uytterhoeven
In-Reply-To: <BANLkTim4q5dK6nOb=pVKbk1c8b-Nh_hBfA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, May 21, 2011 at 4:39 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>>
>> In a hopeless quest to avoid conflicts when merging a new system call
>> and wiring it up I have pulled in bits of net-next and the parisc tree.
>> You have already pulled the net-next bits. The parisc bits in my tree
>> are:
>
> Ok, this just means that I won't pull from you.
Sure. I will try to be a little more patient and resend the pull
request after James has sent the pull request for the parisc tree.
At which point the only unique changes in my tree will be mine.
> It's that simple. We don't do this. Ever.
Hah. I seem to remember bits of pulling from non-rebasing trees being ok
in well defined contexts. This seems like one. Especially when you
have checked with the maintainers.
Plus all of the parisc bits in addition to being in the linux-next
are trivially correct.
> Why the hell did you even worry about wiring up parisc system calls?
> That's not your job.
Because in general it is the job of he who changes something to fix up
every possible place.
Now maybe I went a little too far in trying to resolve the conflicts,
but I did check with the David Miller and James Bottomley and they knew
what I was doing.
Quite honestly adding system calls is a mess that know one seems to
know how to do right. So I flipped a coin and took a stab at it.
Eric
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Nicolas de Pesloüan @ 2011-05-22 2:59 UTC (permalink / raw)
To: Jesse Gross
Cc: Changli Gao, Jiri Pirko, David Miller, netdev, shemminger, kaber,
fubar, eric.dumazet, andy, ebiederm
In-Reply-To: <BANLkTinqFJa-B7E7tonzOKGV4etZHUkUug@mail.gmail.com>
Le 21/05/2011 19:54, Jesse Gross a écrit :
> On Sat, May 21, 2011 at 6:17 AM, Nicolas de Pesloüan
> <nicolas.2p.debian@gmail.com> wrote:
>> Le 21/05/2011 12:43, Changli Gao a écrit :
>>>
>>> On Sat, May 21, 2011 at 3:29 PM, Jiri Pirko<jpirko@redhat.com> wrote:
>>>>
>>>> I do not see a reason why to not emulate that. To make paths as much
>>>> similar as they can be, that is the point of this patch.
>>>>
>>>> I think it would be better to fix an issue you are pointing at
>>>> rather that revert this.
>>>>
>>>
>>> In my opinion, the hardware accelerated VLAN RX is just a special case
>>> of the non hardware accelerated VLAN RX with header reordering. For
>>> promiscuous NICs and bridges, hw-accel-vlan-rx is just disabled.
>>
>> I strongly agree with that.
>>
>> The fact that a skb holds a VLAN tag is not a good enough reason to always
>> remove this tag before giving the skb to protocol handlers.
>>
>> If the user ask for VLAN tag removal, we should remove the tag, possibly
>> using hw-accel untagging if available else software untagging. And if the
>> user doesn't ask for tag removal, we should not untag.
>>
>> In other words, if the user doesn't setup any vlan interface on top of
>> another interface, there is no reason to untag the skb : both hw-accel
>> untagging and software untagging should be disabled.
>
> The problem is that for most hardware vlan stripping is actually the
> common case, not the exception. When you try to disable it frequently
> there are hidden restrictions that cause problems. A few examples:
> * Some NICs can't disable stripping at all.
> * Some NICs can only do tag insertion if stripping is configured on receive.
> * Some NICs can only do hardware offloads (checksum, TSO) if tag
> insertion is used on transmit.
>
> So if you are using vlans then acceleration is pretty much a fact of
> life and the best possible way we can deal with it is to make the
> accelerated and non-accelerated cases behave as similarly as possible.
>
> Before we were trying to dynamically enable/disable vlan acceleration
> based on whether a vlan group was configured and that worked fine for
> vlan devices because acceleration was enabled for it. However, it
> caused an endless series of problems for other devices (such as
> bridging while trunking vlans) due to lost tags, driver bugs, and the
> restrictions above. Some of these can be fixed with driver changes
> but the fact is that dynamically changing behavior just leads to
> problems for the less common cases that are supposedly being fixed.
> It's much better to do the same thing all the time.
Thanks for clarifying.
So, because many limited/buggy hardware exist, we must mimic the behavior in software. 'Sounds good
to me.
And because some setups may still require the skb not to be untagged, may be we need the ability to
re-tag the skb in some situations... When a protocol handler or rx_handler is explicitly registered
on a net_device which expect to receive tagged skb, we should deliver tagged skb to it... Arguably,
this may sound incredible for the general case, but may be required for not-so-special cases like
bridge or protocol analyzer.
Of course, I don't say we should always re-tag: if no protocol handler nor rx_handler were
registered on the parent interface, we don't need the extra work of re-tagging.
What I say is that it shouldn't be the job of protocol handlers or rx_handlers that expect the skb
to be tagged to fix the improper untagging. A generic feature should do it when necessary.
And all this being said, it doesn't mean that we should pollute __netif_receive_skb with special
code for vlan handling.
May be, as suggested by Eric W. Biederman in the V1 thread for this patch, software untagging for
the first level of header should happen before __netif_receive_skb if we only try to mimic hardware
behavior.
And possible later untagging (due to vlan nesting) should be done generically inside
__netif_receive_skb, using rx_handler when appropriate. This would cleanup the general case where no
vlan is involved at all.
Nicolas.
^ permalink raw reply
* Re: [PATCH 0/2] bna: Add Debugfs & Generic Netlink Interfaces to BNA Driver
From: David Miller @ 2011-05-22 3:31 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <E5313AF6F2BFD14293E5FD0F94750F86A5D76F7AC6@HQ1-EXCH01.corp.brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Sat, 21 May 2011 16:06:27 -0700
> Can you please tell what is the state of this patch set? We are wondering if the patches are still under review.
The review feedback you received was that a whole new genetlink protocol
was overkill for the facilities you are providiing at the moment, so the
state of the patch moved to "changed requested"
I saw your response, and I simply disagree with it, so the patches
are staying in that state.
In any event, you don't need to ask me, check patchwork. You make
patchwork absolutely pointless if you ask me what the state of the
patch is, and this makes a lot of extra unnecessary work for me.
Don't do it.
^ permalink raw reply
* Re: [PATCH 0/7] Network namespace manipulation with file descriptors
From: Renato Westphal @ 2011-05-22 4:19 UTC (permalink / raw)
To: David Lamparter
Cc: Eric W. Biederman, Alex Bligh, linux-arch, netdev, linux-kernel,
Linux Containers, linux-fsdevel
In-Reply-To: <20110517153546.GB3762520@jupiter.n2.diac24.net>
Eric,
I'm happy to see that these patches have been integrated into the
mainstream kernel, as you know I'm using them for a while and they are
a essential part of my MPLS/BGP VPN solution, which I will release to
the open-source community anytime soon.
It would also be good if the MPLS core get integrated into mainstream,
but that's another discussion ;)
--
Renato Westphal
^ permalink raw reply
* [PATCH] net: skb_trim explicitely check the linearity instead of data_len
From: emmanuel.grumbach @ 2011-05-22 5:46 UTC (permalink / raw)
To: davem, netdev; +Cc: Emmanuel Grumbach
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The purpose of the check on data_len is to check linearity, so use the inline
helper for this. No overhead and more explicit.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
include/linux/skbuff.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index bf221d6..a4f680c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1439,7 +1439,7 @@ extern int ___pskb_trim(struct sk_buff *skb, unsigned int len);
static inline void __skb_trim(struct sk_buff *skb, unsigned int len)
{
- if (unlikely(skb->data_len)) {
+ if (unlikely(skb_is_nonlinear(skb))) {
WARN_ON(1);
return;
}
--
1.7.1
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Jiri Pirko @ 2011-05-22 6:29 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jesse Gross, Changli Gao, David Miller, netdev, shemminger, kaber,
fubar, eric.dumazet, andy, ebiederm
In-Reply-To: <4DD87C25.4030701@gmail.com>
Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
<snip>
>
>And because some setups may still require the skb not to be untagged,
>may be we need the ability to re-tag the skb in some situations...
>When a protocol handler or rx_handler is explicitly registered on a
>net_device which expect to receive tagged skb, we should deliver
>tagged skb to it... Arguably, this may sound incredible for the
>general case, but may be required for not-so-special cases like
>bridge or protocol analyzer.
Wait, what setups/code require the skb not to be untagged? If there's
such, it should be fixed.
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Eric W. Biederman @ 2011-05-22 6:34 UTC (permalink / raw)
To: Jiri Pirko
Cc: Nicolas de Pesloüan, Jesse Gross, Changli Gao, David Miller,
netdev, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <20110522062915.GA2611@jirka.orion>
Jiri Pirko <jpirko@redhat.com> writes:
> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>
> <snip>
>>
>>And because some setups may still require the skb not to be untagged,
>>may be we need the ability to re-tag the skb in some situations...
>>When a protocol handler or rx_handler is explicitly registered on a
>>net_device which expect to receive tagged skb, we should deliver
>>tagged skb to it... Arguably, this may sound incredible for the
>>general case, but may be required for not-so-special cases like
>>bridge or protocol analyzer.
>
> Wait, what setups/code require the skb not to be untagged? If there's
> such, it should be fixed.
tcpdump on the non-vlan interface for one.
Eric
^ permalink raw reply
* Re: [GIT PULL] Namespace file descriptors for 2.6.40
From: James Bottomley @ 2011-05-22 7:13 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linux Containers, netdev-u79uwXL29TY76Z2rM5mHXA, Linus Torvalds,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
In-Reply-To: <m1boyvpo9r.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
On Sat, 2011-05-21 at 17:33 -0700, Eric W. Biederman wrote:
> Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> writes:
>
> > On Sat, May 21, 2011 at 4:39 PM, Eric W. Biederman
> > <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> >>
> >> In a hopeless quest to avoid conflicts when merging a new system call
> >> and wiring it up I have pulled in bits of net-next and the parisc tree.
> >> You have already pulled the net-next bits. The parisc bits in my tree
> >> are:
> >
> > Ok, this just means that I won't pull from you.
>
> Sure. I will try to be a little more patient and resend the pull
> request after James has sent the pull request for the parisc tree.
> At which point the only unique changes in my tree will be mine.
Right ... effectively you're running a postmerge tree, since you now
depend on bits I have in the parisc tree.
Traditionally, the arch trees tend to go a bit later because they wait
to see if there's any fallout from x86; but this time, I think it looks
OK, so I've sent the pull request:
http://marc.info/?l=linux-parisc&m=130604805417277
As soon as that's in, you should be good to go.
James
> > It's that simple. We don't do this. Ever.
>
> Hah. I seem to remember bits of pulling from non-rebasing trees being ok
> in well defined contexts. This seems like one. Especially when you
> have checked with the maintainers.
>
> Plus all of the parisc bits in addition to being in the linux-next
> are trivially correct.
>
> > Why the hell did you even worry about wiring up parisc system calls?
> > That's not your job.
>
> Because in general it is the job of he who changes something to fix up
> every possible place.
>
> Now maybe I went a little too far in trying to resolve the conflicts,
> but I did check with the David Miller and James Bottomley and they knew
> what I was doing.
>
> Quite honestly adding system calls is a mess that know one seems to
> know how to do right. So I flipped a coin and took a stab at it.
Right, the solution is reasonable and means linux-next doesn't have to
carry a conflict resolution patch for this. It also means we agree on
the syscall numbering ...
The only real mistake was not waiting for the merge sequence: the base
trees have to go first before you can push a postmerge tree.
James
^ permalink raw reply
* Re: Linux 2.6.39
From: CaT @ 2011-05-22 7:22 UTC (permalink / raw)
To: Linus Torvalds, netdev; +Cc: Linux Kernel Mailing List
In-Reply-To: <BANLkTikB37AvEgh1MAFBbYvFaxsL6W11OQ@mail.gmail.com>
Um. Should my routing table be being displayed in reverse order all of
a sudden?
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1
ip route list is similar. I'm sure this is going to break a script or two
(and, perhaps, a mind or two :).
--
"A search of his car uncovered pornography, a homemade sex aid, women's
stockings and a Jack Russell terrier."
- http://www.dailytelegraph.com.au/news/wacky/indeed/story-e6frev20-1111118083480
^ permalink raw reply
* Adding syscalls (was: Re: [GIT PULL] Namespace file descriptors for 2.6.40)
From: Geert Uytterhoeven @ 2011-05-22 8:15 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, linux-kernel, Linux Containers, netdev,
James Bottomley, linux-arch
On Sun, May 22, 2011 at 02:33, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> On Sat, May 21, 2011 at 4:39 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> In a hopeless quest to avoid conflicts when merging a new system call
>>> and wiring it up I have pulled in bits of net-next and the parisc tree.
>>> You have already pulled the net-next bits. The parisc bits in my tree
>>> are:
>>
>> Ok, this just means that I won't pull from you.
>
> Sure. I will try to be a little more patient and resend the pull
> request after James has sent the pull request for the parisc tree.
> At which point the only unique changes in my tree will be mine.
>
>> It's that simple. We don't do this. Ever.
>
> Hah. I seem to remember bits of pulling from non-rebasing trees being ok
> in well defined contexts. This seems like one. Especially when you
> have checked with the maintainers.
>
> Plus all of the parisc bits in addition to being in the linux-next
> are trivially correct.
>
>> Why the hell did you even worry about wiring up parisc system calls?
>> That's not your job.
>
> Because in general it is the job of he who changes something to fix up
> every possible place.
>
> Now maybe I went a little too far in trying to resolve the conflicts,
> but I did check with the David Miller and James Bottomley and they knew
> what I was doing.
>
> Quite honestly adding system calls is a mess that know one seems to
> know how to do right. So I flipped a coin and took a stab at it.
At first, I was delighted to see that somebody took care of adding
syscalls to the
non-popular architectures.
At second, I saw the conflicts in e.g. parisc and m68k due to this.
Hence now I think it's better to leave the wiring up to the
architecture maintainers, as
before.
I'm even thinking to suggest to first let go in the syscall (without
any wiring up, not
even on x86), and let all wiring up be handled afterwards. This would
enforce that
syscalls numbers are not cast in stone, until they hit mainline.
This does mean that scripts/checksyscalls.sh needs to be changed, as initially
new syscalls aren't wired up there neither. The implementation of the
syscalls needs
to announce somehow that it's there and that it's a syscall.
What do you think?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Nicolas de Pesloüan @ 2011-05-22 8:34 UTC (permalink / raw)
To: Jiri Pirko
Cc: Eric W. Biederman, Jesse Gross, Changli Gao, David Miller, netdev,
shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <m17h9jp7js.fsf@fess.ebiederm.org>
Le 22/05/2011 08:34, Eric W. Biederman a écrit :
> Jiri Pirko<jpirko@redhat.com> writes:
>
>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>
>> <snip>
>>>
>>> And because some setups may still require the skb not to be untagged,
>>> may be we need the ability to re-tag the skb in some situations...
>>> When a protocol handler or rx_handler is explicitly registered on a
>>> net_device which expect to receive tagged skb, we should deliver
>>> tagged skb to it... Arguably, this may sound incredible for the
>>> general case, but may be required for not-so-special cases like
>>> bridge or protocol analyzer.
>>
>> Wait, what setups/code require the skb not to be untagged? If there's
>> such, it should be fixed.
>
> tcpdump on the non-vlan interface for one.
bridge is another. More precisely, there is a difference between the following two setups:
1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
2/ eth0 - br0 - eth1
In case 1, it is normal and desirable for the bridge to see untagged skb.
In case 2, it is desirable for the bridge to see untouched (possibly tagged) skb. If current bridge
implementation is able to handle skb from which we removed a tag, in this situation, it means that
bridge currently "fix improper untagging" by itself, by forcing re-tagging on output. I think is
should not be the job of protocol handlers to fix this. Again, a generic feature should to it when
necessary.
Think of the following setups:
3/ eth0 - br0 - eth1.200 - eth1.
4/ eth0 - eth0.100 - br0 - eth1
What if one expect this setup to add (3) or remove (4) one level of vlan nesting? This is precisely
what this setup suggest. How can we instruct the bridge to do so? It is not the bridge
responsibility to do any vlan processing. bridge is expected to... bridge !
Nicolas.
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Changli Gao @ 2011-05-22 8:38 UTC (permalink / raw)
To: Jiri Pirko
Cc: Nicolas de Pesloüan, Jesse Gross, David Miller, netdev,
shemminger, kaber, fubar, eric.dumazet, andy, ebiederm
In-Reply-To: <20110522062915.GA2611@jirka.orion>
On Sun, May 22, 2011 at 2:29 PM, Jiri Pirko <jpirko@redhat.com> wrote:
> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>
> <snip>
>>
>>And because some setups may still require the skb not to be untagged,
>>may be we need the ability to re-tag the skb in some situations...
>>When a protocol handler or rx_handler is explicitly registered on a
>>net_device which expect to receive tagged skb, we should deliver
>>tagged skb to it... Arguably, this may sound incredible for the
>>general case, but may be required for not-so-special cases like
>>bridge or protocol analyzer.
>
> Wait, what setups/code require the skb not to be untagged? If there's
> such, it should be fixed.
>
For a transparent bridge with ports: eth0 and eth1, the vlan tags
need to be preserved.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [GIT PULL] Namespace file descriptors for 2.6.40
From: Ingo Molnar @ 2011-05-22 8:42 UTC (permalink / raw)
To: James Bottomley
Cc: Eric W. Biederman, Linus Torvalds, linux-kernel, Linux Containers,
netdev, Geert Uytterhoeven
In-Reply-To: <1306048393.4092.8.camel@mulgrave.site>
* James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> Traditionally, the arch trees tend to go a bit later because they wait to see
> if there's any fallout from x86; [...]
Not really - most of the arch trees 'traditionally' went late even when the x86
tree itself was monolithic and was itself sent late in the merge window (with
the notable exception of the powerpc tree).
> [...] but this time, I think it looks OK, [...]
That's not really a surprise, there hasn't been a serious 'problem' with the
x86 tree for a long time, roughly since we switched to the finegrained Git
topical split-up maintenance model about two years ago.
[ That split-up also means that there is no 'x86 tree' anymore as such: if you
check lkml we send roughly 20-30 independent trees in the merge window and
have done that for the past ~10 kernel cycles. ]
In fact exactly *because* there's few problems with the x86 topic trees can we
push them so soon: if problems were frequent then 1) we would not be able to be
ready on time and 2) i suspect we'd be pulled in later in the window as well as
a maintainer generally wants to pull low risk items first, high risk items
last, to maximize the utilization of testing capacity.
I agree with Linus's notion in this thread though, a core kernel change should
generally not worry about hooking up rare-arch system calls (concentrate on the
architectures that get tested most) - those are better enabled gradually
anyway.
Also, system call table conflicts are trivial to resolve. Merging in net-next
to avoid such a conflict is like cracking a nut with a sledgehammer.
Thanks,
Ingo
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Michał Mirosław @ 2011-05-22 8:52 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, Eric W. Biederman, Jesse Gross, Changli Gao,
David Miller, netdev, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <4DD8CA87.8040905@gmail.com>
2011/5/22 Nicolas de Pesloüan <nicolas.2p.debian@gmail.com>:
> Le 22/05/2011 08:34, Eric W. Biederman a écrit :
>>
>> Jiri Pirko<jpirko@redhat.com> writes:
>>
>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>>
>>> <snip>
>>>>
>>>> And because some setups may still require the skb not to be untagged,
>>>> may be we need the ability to re-tag the skb in some situations...
>>>> When a protocol handler or rx_handler is explicitly registered on a
>>>> net_device which expect to receive tagged skb, we should deliver
>>>> tagged skb to it... Arguably, this may sound incredible for the
>>>> general case, but may be required for not-so-special cases like
>>>> bridge or protocol analyzer.
>>>
>>> Wait, what setups/code require the skb not to be untagged? If there's
>>> such, it should be fixed.
>>
>> tcpdump on the non-vlan interface for one.
> bridge is another. More precisely, there is a difference between the
> following two setups:
>
> 1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
>
> 2/ eth0 - br0 - eth1
>
> In case 1, it is normal and desirable for the bridge to see untagged skb.
>
> In case 2, it is desirable for the bridge to see untouched (possibly tagged)
> skb. If current bridge implementation is able to handle skb from which we
> removed a tag, in this situation, it means that bridge currently "fix
> improper untagging" by itself, by forcing re-tagging on output. I think is
> should not be the job of protocol handlers to fix this. Again, a generic
> feature should to it when necessary.
>
> Think of the following setups:
>
> 3/ eth0 - br0 - eth1.200 - eth1.
> 4/ eth0 - eth0.100 - br0 - eth1
>
> What if one expect this setup to add (3) or remove (4) one level of vlan
> nesting? This is precisely what this setup suggest. How can we instruct the
> bridge to do so? It is not the bridge responsibility to do any vlan
> processing. bridge is expected to... bridge !
I assumed that this untaging Jiri is implementing does not remove the
tag. It moves the information from skb->data to skb->vlan_tci, but the
information contained is not otherwise changing. All your examples
should work regardless of where the tag is stored.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Nicolas de Pesloüan @ 2011-05-22 9:10 UTC (permalink / raw)
To: Michał Mirosław
Cc: Jiri Pirko, Eric W. Biederman, Jesse Gross, Changli Gao,
David Miller, netdev, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <BANLkTi=B4c-A9ZC2apE+ZOQmgdzaJb0oEQ@mail.gmail.com>
Le 22/05/2011 10:52, Michał Mirosław a écrit :
> 2011/5/22 Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>:
>> Le 22/05/2011 08:34, Eric W. Biederman a écrit :
>>>
>>> Jiri Pirko<jpirko@redhat.com> writes:
>>>
>>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>>>
>>>> <snip>
>>>>>
>>>>> And because some setups may still require the skb not to be untagged,
>>>>> may be we need the ability to re-tag the skb in some situations...
>>>>> When a protocol handler or rx_handler is explicitly registered on a
>>>>> net_device which expect to receive tagged skb, we should deliver
>>>>> tagged skb to it... Arguably, this may sound incredible for the
>>>>> general case, but may be required for not-so-special cases like
>>>>> bridge or protocol analyzer.
>>>>
>>>> Wait, what setups/code require the skb not to be untagged? If there's
>>>> such, it should be fixed.
>>>
>>> tcpdump on the non-vlan interface for one.
>> bridge is another. More precisely, there is a difference between the
>> following two setups:
>>
>> 1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
>>
>> 2/ eth0 - br0 - eth1
>>
>> In case 1, it is normal and desirable for the bridge to see untagged skb.
>>
>> In case 2, it is desirable for the bridge to see untouched (possibly tagged)
>> skb. If current bridge implementation is able to handle skb from which we
>> removed a tag, in this situation, it means that bridge currently "fix
>> improper untagging" by itself, by forcing re-tagging on output. I think is
>> should not be the job of protocol handlers to fix this. Again, a generic
>> feature should to it when necessary.
>>
>> Think of the following setups:
>>
>> 3/ eth0 - br0 - eth1.200 - eth1.
>> 4/ eth0 - eth0.100 - br0 - eth1
>>
>> What if one expect this setup to add (3) or remove (4) one level of vlan
>> nesting? This is precisely what this setup suggest. How can we instruct the
>> bridge to do so? It is not the bridge responsibility to do any vlan
>> processing. bridge is expected to... bridge !
>
> I assumed that this untaging Jiri is implementing does not remove the
> tag. It moves the information from skb->data to skb->vlan_tci, but the
> information contained is not otherwise changing. All your examples
> should work regardless of where the tag is stored.
I assumed (but didn't tested) that this untagging also change the starting point of the payload of
the packet. So protocol handlers expecting to have the raw packet won't see the vlan header.
Nicolas.
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Michał Mirosław @ 2011-05-22 9:20 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, Eric W. Biederman, Jesse Gross, Changli Gao,
David Miller, netdev, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <4DD8D2FE.4080204@gmail.com>
W dniu 22 maja 2011 11:10 użytkownik Nicolas de Pesloüan
<nicolas.2p.debian@gmail.com> napisał:
> Le 22/05/2011 10:52, Michał Mirosław a écrit :
>>
>> 2011/5/22 Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>:
>>>
>>> Le 22/05/2011 08:34, Eric W. Biederman a écrit :
>>>>
>>>> Jiri Pirko<jpirko@redhat.com> writes:
>>>>
>>>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com
>>>>> wrote:
>>>>>
>>>>> <snip>
>>>>>>
>>>>>> And because some setups may still require the skb not to be untagged,
>>>>>> may be we need the ability to re-tag the skb in some situations...
>>>>>> When a protocol handler or rx_handler is explicitly registered on a
>>>>>> net_device which expect to receive tagged skb, we should deliver
>>>>>> tagged skb to it... Arguably, this may sound incredible for the
>>>>>> general case, but may be required for not-so-special cases like
>>>>>> bridge or protocol analyzer.
>>>>>
>>>>> Wait, what setups/code require the skb not to be untagged? If there's
>>>>> such, it should be fixed.
>>>>
>>>> tcpdump on the non-vlan interface for one.
>>>
>>> bridge is another. More precisely, there is a difference between the
>>> following two setups:
>>>
>>> 1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
>>>
>>> 2/ eth0 - br0 - eth1
>>>
>>> In case 1, it is normal and desirable for the bridge to see untagged skb.
>>>
>>> In case 2, it is desirable for the bridge to see untouched (possibly
>>> tagged)
>>> skb. If current bridge implementation is able to handle skb from which we
>>> removed a tag, in this situation, it means that bridge currently "fix
>>> improper untagging" by itself, by forcing re-tagging on output. I think
>>> is
>>> should not be the job of protocol handlers to fix this. Again, a generic
>>> feature should to it when necessary.
>>>
>>> Think of the following setups:
>>>
>>> 3/ eth0 - br0 - eth1.200 - eth1.
>>> 4/ eth0 - eth0.100 - br0 - eth1
>>>
>>> What if one expect this setup to add (3) or remove (4) one level of vlan
>>> nesting? This is precisely what this setup suggest. How can we instruct
>>> the
>>> bridge to do so? It is not the bridge responsibility to do any vlan
>>> processing. bridge is expected to... bridge !
>>
>> I assumed that this untaging Jiri is implementing does not remove the
>> tag. It moves the information from skb->data to skb->vlan_tci, but the
>> information contained is not otherwise changing. All your examples
>> should work regardless of where the tag is stored.
>
> I assumed (but didn't tested) that this untagging also change the starting
> point of the payload of the packet. So protocol handlers expecting to have
> the raw packet won't see the vlan header.
That would also be the case with hardware stripped tags - they need to
look into skb->vlan_tci anyway.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Jiri Pirko @ 2011-05-22 9:36 UTC (permalink / raw)
To: Michał Mirosław
Cc: Nicolas de Pesloüan, Eric W. Biederman, Jesse Gross,
Changli Gao, David Miller, netdev, shemminger, kaber, fubar,
eric.dumazet, andy
In-Reply-To: <BANLkTimQ6LAWbZMCjBhqA5By8jvxwnfjVg@mail.gmail.com>
Sun, May 22, 2011 at 11:20:09AM CEST, mirqus@gmail.com wrote:
>W dniu 22 maja 2011 11:10 użytkownik Nicolas de Pesloüan
><nicolas.2p.debian@gmail.com> napisał:
>> Le 22/05/2011 10:52, Michał Mirosław a écrit :
>>>
>>> 2011/5/22 Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>:
>>>>
>>>> Le 22/05/2011 08:34, Eric W. Biederman a écrit :
>>>>>
>>>>> Jiri Pirko<jpirko@redhat.com> writes:
>>>>>
>>>>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>> <snip>
>>>>>>>
>>>>>>> And because some setups may still require the skb not to be untagged,
>>>>>>> may be we need the ability to re-tag the skb in some situations...
>>>>>>> When a protocol handler or rx_handler is explicitly registered on a
>>>>>>> net_device which expect to receive tagged skb, we should deliver
>>>>>>> tagged skb to it... Arguably, this may sound incredible for the
>>>>>>> general case, but may be required for not-so-special cases like
>>>>>>> bridge or protocol analyzer.
>>>>>>
>>>>>> Wait, what setups/code require the skb not to be untagged? If there's
>>>>>> such, it should be fixed.
>>>>>
>>>>> tcpdump on the non-vlan interface for one.
>>>>
>>>> bridge is another. More precisely, there is a difference between the
>>>> following two setups:
>>>>
>>>> 1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
>>>>
>>>> 2/ eth0 - br0 - eth1
>>>>
>>>> In case 1, it is normal and desirable for the bridge to see untagged skb.
>>>>
>>>> In case 2, it is desirable for the bridge to see untouched (possibly
>>>> tagged)
>>>> skb. If current bridge implementation is able to handle skb from which we
>>>> removed a tag, in this situation, it means that bridge currently "fix
>>>> improper untagging" by itself, by forcing re-tagging on output. I think
>>>> is
>>>> should not be the job of protocol handlers to fix this. Again, a generic
>>>> feature should to it when necessary.
>>>>
>>>> Think of the following setups:
>>>>
>>>> 3/ eth0 - br0 - eth1.200 - eth1.
>>>> 4/ eth0 - eth0.100 - br0 - eth1
>>>>
>>>> What if one expect this setup to add (3) or remove (4) one level of vlan
>>>> nesting? This is precisely what this setup suggest. How can we instruct
>>>> the
>>>> bridge to do so? It is not the bridge responsibility to do any vlan
>>>> processing. bridge is expected to... bridge !
>>>
>>> I assumed that this untaging Jiri is implementing does not remove the
>>> tag. It moves the information from skb->data to skb->vlan_tci, but the
>>> information contained is not otherwise changing. All your examples
>>> should work regardless of where the tag is stored.
>>
>> I assumed (but didn't tested) that this untagging also change the starting
>> point of the payload of the packet. So protocol handlers expecting to have
>> the raw packet won't see the vlan header.
>
>That would also be the case with hardware stripped tags - they need to
>look into skb->vlan_tci anyway.
Exactly. Nicolas, I do not see anything wrong on always untagging in all
your setups. As Michal said, vlan_tci keeps the info.
Jirka
>
>Best Regards,
>Michał Mirosław
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Jiri Pirko @ 2011-05-22 9:37 UTC (permalink / raw)
To: Changli Gao
Cc: Nicolas de Pesloüan, Jesse Gross, David Miller, netdev,
shemminger, kaber, fubar, eric.dumazet, andy, ebiederm
In-Reply-To: <BANLkTinEnHLx1CVh8p0ejLkcaqoLHw2nOA@mail.gmail.com>
Sun, May 22, 2011 at 10:38:45AM CEST, xiaosuo@gmail.com wrote:
>On Sun, May 22, 2011 at 2:29 PM, Jiri Pirko <jpirko@redhat.com> wrote:
>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>
>> <snip>
>>>
>>>And because some setups may still require the skb not to be untagged,
>>>may be we need the ability to re-tag the skb in some situations...
>>>When a protocol handler or rx_handler is explicitly registered on a
>>>net_device which expect to receive tagged skb, we should deliver
>>>tagged skb to it... Arguably, this may sound incredible for the
>>>general case, but may be required for not-so-special cases like
>>>bridge or protocol analyzer.
>>
>> Wait, what setups/code require the skb not to be untagged? If there's
>> such, it should be fixed.
>>
>
>For a transparent bridge with ports: eth0 and eth1, the vlan tags
>need to be preserved.
Yet they are - in skb->vlan_tci. I see no problem here. It's the same as
if the NIC does hw-untagging itself.
Jirka
>
>--
>Regards,
>Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Nicolas de Pesloüan @ 2011-05-22 9:53 UTC (permalink / raw)
To: Jiri Pirko
Cc: Michał Mirosław, Eric W. Biederman, Jesse Gross,
Changli Gao, David Miller, netdev, shemminger, kaber, fubar,
eric.dumazet, andy
In-Reply-To: <20110522093614.GB2611@jirka.orion>
Le 22/05/2011 11:36, Jiri Pirko a écrit :
> Sun, May 22, 2011 at 11:20:09AM CEST, mirqus@gmail.com wrote:
>> W dniu 22 maja 2011 11:10 użytkownik Nicolas de Pesloüan
>> <nicolas.2p.debian@gmail.com> napisał:
>>> Le 22/05/2011 10:52, Michał Mirosław a écrit :
>>>>
>>>> 2011/5/22 Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>:
>>>>>
>>>>> Le 22/05/2011 08:34, Eric W. Biederman a écrit :
>>>>>>
>>>>>> Jiri Pirko<jpirko@redhat.com> writes:
>>>>>>
>>>>>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com
>>>>>>> wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>>
>>>>>>>> And because some setups may still require the skb not to be untagged,
>>>>>>>> may be we need the ability to re-tag the skb in some situations...
>>>>>>>> When a protocol handler or rx_handler is explicitly registered on a
>>>>>>>> net_device which expect to receive tagged skb, we should deliver
>>>>>>>> tagged skb to it... Arguably, this may sound incredible for the
>>>>>>>> general case, but may be required for not-so-special cases like
>>>>>>>> bridge or protocol analyzer.
>>>>>>>
>>>>>>> Wait, what setups/code require the skb not to be untagged? If there's
>>>>>>> such, it should be fixed.
>>>>>>
>>>>>> tcpdump on the non-vlan interface for one.
>>>>>
>>>>> bridge is another. More precisely, there is a difference between the
>>>>> following two setups:
>>>>>
>>>>> 1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
>>>>>
>>>>> 2/ eth0 - br0 - eth1
>>>>>
>>>>> In case 1, it is normal and desirable for the bridge to see untagged skb.
>>>>>
>>>>> In case 2, it is desirable for the bridge to see untouched (possibly
>>>>> tagged)
>>>>> skb. If current bridge implementation is able to handle skb from which we
>>>>> removed a tag, in this situation, it means that bridge currently "fix
>>>>> improper untagging" by itself, by forcing re-tagging on output. I think
>>>>> is
>>>>> should not be the job of protocol handlers to fix this. Again, a generic
>>>>> feature should to it when necessary.
>>>>>
>>>>> Think of the following setups:
>>>>>
>>>>> 3/ eth0 - br0 - eth1.200 - eth1.
>>>>> 4/ eth0 - eth0.100 - br0 - eth1
>>>>>
>>>>> What if one expect this setup to add (3) or remove (4) one level of vlan
>>>>> nesting? This is precisely what this setup suggest. How can we instruct
>>>>> the
>>>>> bridge to do so? It is not the bridge responsibility to do any vlan
>>>>> processing. bridge is expected to... bridge !
>>>>
>>>> I assumed that this untaging Jiri is implementing does not remove the
>>>> tag. It moves the information from skb->data to skb->vlan_tci, but the
>>>> information contained is not otherwise changing. All your examples
>>>> should work regardless of where the tag is stored.
>>>
>>> I assumed (but didn't tested) that this untagging also change the starting
>>> point of the payload of the packet. So protocol handlers expecting to have
>>> the raw packet won't see the vlan header.
>>
>> That would also be the case with hardware stripped tags - they need to
>> look into skb->vlan_tci anyway.
>
> Exactly. Nicolas, I do not see anything wrong on always untagging in all
> your setups. As Michal said, vlan_tci keeps the info.
I understand this.
But I don't understand how the bridge code is expected to know whether it should re-tag the packet
or not before forwarding and which value to use as the egress vlan tag.
1/ eth0 - br0 - eth1 : the bridge is expected to retag using skb->vlan_tci value.
2/ eth0 - eth0.100 - br0 - eth1.200 - eth1 : the bridge is expected to retag using a different value
than skb->vlan_tci.
3/ eth0 - eth0.100 - br0 - eth1 : the bridge is expected not to re-tag, because the expected
behavior of this setup is to untag while crossing the bridge.
4/ eth0 - eth0.100 - eth0.100.300 - br0 - eth1.400 - eth1.200 - eth1 : the bridge is expected to
retag using a different value than skb->vlan_tci. What value would skb->vlan_tci hold when the skb
will be delivered to the bridge? 100 or 300?
From my point of view, in both setup, the bridge will receive a single value in skb->vlan_tci and
will lack any other indication to help it decide how to retag when forwarding.
I'm not against your idea to mimic hw-accel in software. But I'm concern about troubles for those
who expect to have access to untouched packet. Your patch didn't cause those troubles to start
happening, but cause them to always happen. Before your patch, someone had the option to use
non-hw-accel NIC or to disable hw-accel feature if possible. Now, it's no more possible.
Nicolas.
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Michał Mirosław @ 2011-05-22 10:04 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, Eric W. Biederman, Jesse Gross, Changli Gao,
David Miller, netdev, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <4DD8DD06.6070202@gmail.com>
2011/5/22 Nicolas de Pesloüan <nicolas.2p.debian@gmail.com>:
> Le 22/05/2011 11:36, Jiri Pirko a écrit :
>> Sun, May 22, 2011 at 11:20:09AM CEST, mirqus@gmail.com wrote:
>>> W dniu 22 maja 2011 11:10 użytkownik Nicolas de Pesloüan
>>> <nicolas.2p.debian@gmail.com> napisał:
>>>> Le 22/05/2011 10:52, Michał Mirosław a écrit :
>>>>> I assumed that this untaging Jiri is implementing does not remove the
>>>>> tag. It moves the information from skb->data to skb->vlan_tci, but the
>>>>> information contained is not otherwise changing. All your examples
>>>>> should work regardless of where the tag is stored.
>>>> I assumed (but didn't tested) that this untagging also change the
>>>> starting
>>>> point of the payload of the packet. So protocol handlers expecting to
>>>> have
>>>> the raw packet won't see the vlan header.
>>> That would also be the case with hardware stripped tags - they need to
>>> look into skb->vlan_tci anyway.
>> Exactly. Nicolas, I do not see anything wrong on always untagging in all
>> your setups. As Michal said, vlan_tci keeps the info.
>
> I understand this.
>
> But I don't understand how the bridge code is expected to know whether it
> should re-tag the packet or not before forwarding and which value to use as
> the egress vlan tag.
>
> 1/ eth0 - br0 - eth1 : the bridge is expected to retag using skb->vlan_tci
> value.
>
> 2/ eth0 - eth0.100 - br0 - eth1.200 - eth1 : the bridge is expected to retag
> using a different value than skb->vlan_tci.
> 3/ eth0 - eth0.100 - br0 - eth1 : the bridge is expected not to re-tag,
> because the expected behavior of this setup is to untag while crossing the
> bridge.
>
> 4/ eth0 - eth0.100 - eth0.100.300 - br0 - eth1.400 - eth1.200 - eth1 : the
> bridge is expected to retag using a different value than skb->vlan_tci. What
> value would skb->vlan_tci hold when the skb will be delivered to the bridge?
> 100 or 300?
>
> From my point of view, in both setup, the bridge will receive a single value
> in skb->vlan_tci and will lack any other indication to help it decide how to
> retag when forwarding.
Packets looking like they came from eth0.100 will have skb->vlan_tci
cleared (like taking packet out of a tunnel) and then possibly filled
again with inner tag. It's really convenient to thing of VLANs as
tunnels.
Best Regards,
Michał Mirosław
^ permalink raw reply
* [Patch] pktgen: use vzalloc_node() instead of vmalloc_node() + memset()
From: Américo Wang @ 2011-05-22 10:17 UTC (permalink / raw)
To: Linux Kernel Network Developers; +Cc: David S. Miller
[-- Attachment #1: Type: text/plain, Size: 101 bytes --]
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
---
[-- Attachment #2: net-pktgen-use-vzalloc_node.diff --]
[-- Type: text/x-patch, Size: 657 bytes --]
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 67870e9..3b85c0d 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3544,13 +3544,12 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname)
return -ENOMEM;
strcpy(pkt_dev->odevname, ifname);
- pkt_dev->flows = vmalloc_node(MAX_CFLOWS * sizeof(struct flow_state),
+ pkt_dev->flows = vzalloc_node(MAX_CFLOWS * sizeof(struct flow_state),
node);
if (pkt_dev->flows == NULL) {
kfree(pkt_dev);
return -ENOMEM;
}
- memset(pkt_dev->flows, 0, MAX_CFLOWS * sizeof(struct flow_state));
pkt_dev->removal_mark = 0;
pkt_dev->min_pkt_size = ETH_ZLEN;
^ permalink raw reply related
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Changli Gao @ 2011-05-22 10:17 UTC (permalink / raw)
To: Jiri Pirko
Cc: Nicolas de Pesloüan, Jesse Gross, David Miller, netdev,
shemminger, kaber, fubar, eric.dumazet, andy, ebiederm
In-Reply-To: <20110522093758.GC2611@jirka.orion>
On Sun, May 22, 2011 at 5:37 PM, Jiri Pirko <jpirko@redhat.com> wrote:
>>
>>For a transparent bridge with ports: eth0 and eth1, the vlan tags
>>need to be preserved.
>
> Yet they are - in skb->vlan_tci. I see no problem here. It's the same as
> if the NIC does hw-untagging itself.
>
Although they are in skb->vlan_tci, but the xmit nic, which doesn't
support hw-accel-vlan-tx, doesn't use them to tag the outgoing
packets. Correct me if I am wrong.
I know the current software emulation doesn't strip the vlan headers,
but I want to know in what way you fix the current misuse of
vlan_check_reorder_header(). If you emulation what the HW does
exactly, I am afraid more work are needed. IMHO, this way is more
dangerous than just a revert for this bugfix cycle.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Eric W. Biederman @ 2011-05-22 10:26 UTC (permalink / raw)
To: Changli Gao
Cc: Jiri Pirko, Nicolas de Pesloüan, Jesse Gross, David Miller,
netdev, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <BANLkTin6u7VptTm3se_bLdEeTOz2OVc_Rw@mail.gmail.com>
Changli Gao <xiaosuo@gmail.com> writes:
> On Sun, May 22, 2011 at 5:37 PM, Jiri Pirko <jpirko@redhat.com> wrote:
>>>
>>>For a transparent bridge with ports: eth0 and eth1, the vlan tags
>>>need to be preserved.
>>
>> Yet they are - in skb->vlan_tci. I see no problem here. It's the same as
>> if the NIC does hw-untagging itself.
>>
>
> Although they are in skb->vlan_tci, but the xmit nic, which doesn't
> support hw-accel-vlan-tx, doesn't use them to tag the outgoing
> packets. Correct me if I am wrong.
There is software emulation in dev_hard_start_xmit for the nics
that don't support the feature. So we will properly add tags.
Eric
^ permalink raw reply
* Re: [PATCH v4 1/1] can: add pruss CAN driver.
From: Arnd Bergmann @ 2011-05-22 10:30 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
Alan Cox, Subhasish Ghosh, nsekhar-l0cyMroinI0, open list,
CAN NETWORK DRIVERS, Marc Kleine-Budde,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Netdev-u79uwXL29TY76Z2rM5mHXA, m-watkins-l0cyMroinI0,
Wolfgang Grandegger
In-Reply-To: <4DCBF1B6.6000104-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
On Thursday 12 May 2011 16:41:58 Oliver Hartkopp wrote:
> E.g. assume you need the CAN-IDs 0x100, 0x200 and 0x300 in your application
> and for that reason you configure these IDs in the pruss CAN driver.
>
> What if someone generates a 100% CAN busload exactly on CAN-ID 0x100 then?
>
> Worst case (1MBit/s, DLC=0) you would need to handle about 21.000 irqs/s for
> the correctly received CAN frames with the filtered CAN-ID 0x100 ...
Then I guess the main thing that a "smart" CAN implementation like pruss
should do is interrupt mitigation. When you have a constant flow of
packets coming in, the hardware should be able to DMA a lot of
them into kernel memory before the driver is required to pick them up,
and only get into interrupt driven mode when the kernel has managed
to process all outstanding packets.
> This all depends heavily on Linux networking (skb handling, caching, etc) and
> is pretty fast and optimized!! That was also the reason why it ran on the old
> PowerPC that smoothly. The mostly seen effect if anything drops is when the
> application (holding the socket) was not fast enough to handle the incoming
> data. NB: For that reason we implemented a CAN content filter (CAN_BCM) that
> is able to do content filtering and timeout monitoring in Kernelspace - all
> performed in the SoftIRQ.
Right, dropping packets that no process is waiting for should be done as
early as possible. In pruss-can, the idea was to do it in hardware, which
doesn't really work all that well for the reasons discussed before.
Dropping the frames in the NAPI poll function (softirq time) seems like a
logical choice.
> Having 'Mailboxes' bound to CAN-IDs is something that's useful for 8/16 bit
> CPUs where an application is tightly bound to the embedded ECUs functionality.
Makes sense.
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox