* Re: e100 + VLANs?
From: Eric Dumazet @ 2011-10-10 15:05 UTC (permalink / raw)
To: Michael Tokarev; +Cc: David Lamparter, jeffrey.t.kirsher, netdev
In-Reply-To: <4E9307CB.4050704@msgid.tls.msk.ru>
Le lundi 10 octobre 2011 à 18:57 +0400, Michael Tokarev a écrit :
> 10.10.2011 14:19, David Lamparter wrote:
> > On Sat, Oct 08, 2011 at 11:34:40AM -0700, Jeff Kirsher wrote:
> >> On 10/08/2011 09:24 AM, Eric Dumazet wrote:
> >>> Le samedi 08 octobre 2011 à 14:08 +0400, Michael Tokarev a écrit :
> >>>>> Yesterday I tried to use 802.1Q VLAN tagging with an (oldish)
> >>>>> e100-driven network card, identified by lspci like this:
> >>>>>
> >>>>> 00:12.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 02)
> >>>>>
> >>>>> Just to discover that it does not quite work: packets of
> >>>>> size 1497+ bytes gets lost.
> > [...]
> >>> e100 driver seems VLAN enabled at a first glance.
> >> Eric is correct, that e100 does support VLANs.
> >>
> >> In addition to Eric's suggestion, can you also provide all the output of
> >> lspci -vvv for the network card?
> >
> > I'm opening the lore box here, but early e100 cards AFAIK have a
> > hardware limit at 1500 (+18 src/dst/proto) bytes. At least, Juniper's
> > JUNOS does not support full-sized .1Q on their e100 control plane
> > interfaces...
>
> Thank you all for the suggestions and feedback.
>
> The card may indeed be quite old, I don't know where it come from and
> when. Here's lspci -vvv for it:
>
> 00:12.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 02)
> Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 66 (2000ns min, 14000ns max)
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at fe200000 (32-bit, prefetchable) [size=4K]
> Region 1: I/O ports at 2400 [size=32]
> Region 2: Memory at fc000000 (32-bit, non-prefetchable) [size=1M]
> [virtual] Expansion ROM at 30100000 [disabled] [size=1M]
> Kernel driver in use: e100
>
>
> I tried to set it up to talk to another machine in order to find
> out where the packets gets lost. But had another complication
> on the way: it does not "want" to work with 802.1Q VLANs anymore
> at all... ;)
>
> When pinging this NIC from another machine over VLAN5, I see
> ARP packets coming to it, gets recognized and replies going
> back, all on vlan 5. But on the other side, replies comes
> WITHOUT a VLAN tag!
>
> From this NIC's point of view, capturing on whole ethX:
>
> 00:1f:c6:ef:e5:1b > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.48.11.2 tell 10.48.11.1, length 42
> 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.48.11.2 is-at 00:90:27:30:6d:1c, length 28
>
> From the partner point of view, also on whole ethX:
>
> 00:1f:c6:ef:e5:1b > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.48.11.2 tell 10.48.11.1, length 28
> 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.48.11.2 is-at 00:90:27:30:6d:1c, length 46
>
> So, the tag gets eaten somewhere along the way... ;)
>
> And I can't really recreate the situation which I had - I know
> some packets were flowing, so at least ARP worked. Now it
> does not work anymore.
What the 'partner' setup looks like ?
ip link
ip addr
ip ro
^ permalink raw reply
* Re: [PATCH 9/9] net: add opaque struct around skb frag page
From: Eric Dumazet @ 2011-10-10 15:09 UTC (permalink / raw)
To: Ian Campbell; +Cc: netdev
In-Reply-To: <1318245101-16890-9-git-send-email-ian.campbell@citrix.com>
Le lundi 10 octobre 2011 à 12:11 +0100, Ian Campbell a écrit :
> I've split this bit out of the skb frag destructor patch since it helps enforce
> the use of the fragment API.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> include/linux/skbuff.h | 10 ++++++----
> net/core/skbuff.c | 6 +++---
> 2 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index ac6b05a..f881d75 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -135,7 +135,9 @@ struct sk_buff;
> typedef struct skb_frag_struct skb_frag_t;
>
> struct skb_frag_struct {
> - struct page *page;
> + struct {
> + struct page *p;
> + } page;
Oh well, why dont you rename page to something else, say frag_page ?
^ permalink raw reply
* Re: loopback IP alias breaks tftp?
From: Josh Boyer @ 2011-10-10 15:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Joel Sing, Julian Anastasov, netdev, francis.souyri
In-Reply-To: <1317990201.3207.15.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Fri, Oct 07, 2011 at 02:23:21PM +0200, Eric Dumazet wrote:
> Le vendredi 07 octobre 2011 à 14:04 +0200, Eric Dumazet a écrit :
>
> > Its a completely different problem IMHO : You describe a tftp server
> > bug.
> >
> > Say your tftp server is multihomed with 3 different IPS :
> >
> > 192.168.20.21, 192.168.20.22, 192.168.20.23
> >
> > And tftp server listens to any address (UDP port 69) : 0.0.0.0:69
> >
> > When receiving a request on 192.168.20.22, it should use same source
> > address, not let the system chose a "random or whatever policy" one.
> >
> >
> >
> > So I would suggest to check/fix if TFTP server uses the correct socket
> > API to get both the client IP and its own IP in each UDP datagram
> >
> > -> setsockopt(fd, IPPROTO_IP, &on, sizeof(on))
>
> > This permits tftp server to use the same "struct in_pktinfo" for replies, forcing a correct source address.
> >
>
> By the way, there is no need for tftp change :
>
> Just launch several tftpd instances, and bind each them to one
> particular IP.
>
> If started from xinetd.d :
>
> $ cat /etc/xinetd.d/tftp1
> service tftp
> {
> socket_type = dgram
> protocol = udp
> wait = yes
> user = root
> server = /usr/sbin/in.tftpd
> server_args = -s /tftpboot
> disable = no
> bind = 192.168.20.21
> per_source = 11
> cps = 100 2
> flags = IPv4
> }
(I've CC'd the original bug reporter now.)
I did this locally and it still timed out. So the bind alone is not
enough to fix the problem. At least not on lo:0 127.0.0.2.
Changing the source address in the routing table as Joel suggested does
work around the problem.
So, in summary, either the TFTP server needs to be changed per your
original suggestion, or the routing table needs to be altered for every
alias? Is that correct?
josh
^ permalink raw reply
* Re: e100 + VLANs?
From: David Lamparter @ 2011-10-10 15:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Michael Tokarev, David Lamparter, jeffrey.t.kirsher, netdev
In-Reply-To: <1318259152.3227.0.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, Oct 10, 2011 at 05:05:52PM +0200, Eric Dumazet wrote:
> > When pinging this NIC from another machine over VLAN5, I see
> > ARP packets coming to it, gets recognized and replies going
> > back, all on vlan 5. But on the other side, replies comes
> > WITHOUT a VLAN tag!
> >
> > From this NIC's point of view, capturing on whole ethX:
> >
> > 00:1f:c6:ef:e5:1b > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.48.11.2 tell 10.48.11.1, length 42
> > 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.48.11.2 is-at 00:90:27:30:6d:1c, length 28
> >
> > From the partner point of view, also on whole ethX:
> >
> > 00:1f:c6:ef:e5:1b > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.48.11.2 tell 10.48.11.1, length 28
> > 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.48.11.2 is-at 00:90:27:30:6d:1c, length 46
> >
> > So, the tag gets eaten somewhere along the way... ;)
Hmm. Looks like broken VLAN TX offload, but the driver doesn't even
implement VLAN offload. Maybe it's broken in its non-implementation...
Your "partner" is a known-good setup and can be assumed to be working
correctly? This is over a crossover cable, no evil switches involved?
> > And I can't really recreate the situation which I had - I know
> > some packets were flowing, so at least ARP worked. Now it
> > does not work anymore.
>
> What the 'partner' setup looks like ?
>
> ip link
> ip addr
> ip ro
'local' setup too please :)
-David
^ permalink raw reply
* Re: [PATCH 9/9] net: add opaque struct around skb frag page
From: Ian Campbell @ 2011-10-10 15:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1318259375.3227.1.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, 2011-10-10 at 16:09 +0100, Eric Dumazet wrote:
> Le lundi 10 octobre 2011 à 12:11 +0100, Ian Campbell a écrit :
> > I've split this bit out of the skb frag destructor patch since it helps enforce
> > the use of the fragment API.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> > include/linux/skbuff.h | 10 ++++++----
> > net/core/skbuff.c | 6 +++---
> > 2 files changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > index ac6b05a..f881d75 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -135,7 +135,9 @@ struct sk_buff;
> > typedef struct skb_frag_struct skb_frag_t;
> >
> > struct skb_frag_struct {
> > - struct page *page;
> > + struct {
> > + struct page *p;
> > + } page;
>
> Oh well, why dont you rename page to something else, say frag_page ?
I looked at renaming this field and the impact was far larger than this
(already huge) set of series.
Keeping the name for the outer struct also has the nice property that
when the struct becomes something like:
struct {
struct page *p;
struct skb_frag_destructor *destr;
} page;
existing code which does
fraga->page = fragb->page
will carry the destructor along magically without needing modification.
Ian.
>
>
>
^ permalink raw reply
* Re: loopback IP alias breaks tftp?
From: Olaf van der Spek @ 2011-10-10 15:15 UTC (permalink / raw)
To: Josh Boyer
Cc: Eric Dumazet, Joel Sing, Julian Anastasov, netdev, francis.souyri
In-Reply-To: <20111010151058.GD1165@zod.bos.redhat.com>
> On Fri, Oct 07, 2011 at 02:23:21PM +0200, Eric Dumazet wrote:
>> By the way, there is no need for tftp change :
>>
>> Just launch several tftpd instances, and bind each them to one
>> particular IP.
>>
>> If started from xinetd.d :
Isn't that a bad way to work around this issue?
It'd require you to duplicate your IP config for every daemon that
listens on UDP interfaces.
What about IP addresses that are added/deleted after the daemon is launchad?
Olaf
^ permalink raw reply
* Re: loopback IP alias breaks tftp?
From: Eric Dumazet @ 2011-10-10 15:22 UTC (permalink / raw)
To: Olaf van der Spek
Cc: Josh Boyer, Joel Sing, Julian Anastasov, netdev, francis.souyri
In-Reply-To: <CAGVGHmsF3JBqpqzKa_Fp6oOcVKX5BKgJUG=UJvPZcNgKiSsrRA@mail.gmail.com>
Le lundi 10 octobre 2011 à 17:15 +0200, Olaf van der Spek a écrit :
> > On Fri, Oct 07, 2011 at 02:23:21PM +0200, Eric Dumazet wrote:
> >> By the way, there is no need for tftp change :
> >>
> >> Just launch several tftpd instances, and bind each them to one
> >> particular IP.
> >>
> >> If started from xinetd.d :
>
> Isn't that a bad way to work around this issue?
> It'd require you to duplicate your IP config for every daemon that
> listens on UDP interfaces.
> What about IP addresses that are added/deleted after the daemon is launchad?
>
> Olaf
Thats a pretty common problem, even prior to discussed commit.
If you take a look at common UDP daemons, they have to setup a listener
for each IP address, OR use the correct API ( setsockopt(fd, IPPROTO_IP,
&on, sizeof(on)) and handle IP_PKTINFO ancillary message)
^ permalink raw reply
* Re: e100 + VLANs?
From: Eric Dumazet @ 2011-10-10 15:23 UTC (permalink / raw)
To: David Lamparter; +Cc: Michael Tokarev, jeffrey.t.kirsher, netdev
In-Reply-To: <20111010151343.GB3260852@jupiter.n2.diac24.net>
Le lundi 10 octobre 2011 à 17:13 +0200, David Lamparter a écrit :
> On Mon, Oct 10, 2011 at 05:05:52PM +0200, Eric Dumazet wrote:
> > > When pinging this NIC from another machine over VLAN5, I see
> > > ARP packets coming to it, gets recognized and replies going
> > > back, all on vlan 5. But on the other side, replies comes
> > > WITHOUT a VLAN tag!
> > >
> > > From this NIC's point of view, capturing on whole ethX:
> > >
> > > 00:1f:c6:ef:e5:1b > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.48.11.2 tell 10.48.11.1, length 42
> > > 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.48.11.2 is-at 00:90:27:30:6d:1c, length 28
> > >
> > > From the partner point of view, also on whole ethX:
> > >
> > > 00:1f:c6:ef:e5:1b > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.48.11.2 tell 10.48.11.1, length 28
> > > 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.48.11.2 is-at 00:90:27:30:6d:1c, length 46
> > >
> > > So, the tag gets eaten somewhere along the way... ;)
>
> Hmm. Looks like broken VLAN TX offload, but the driver doesn't even
> implement VLAN offload. Maybe it's broken in its non-implementation...
>
> Your "partner" is a known-good setup and can be assumed to be working
> correctly? This is over a crossover cable, no evil switches involved?
>
> > > And I can't really recreate the situation which I had - I know
> > > some packets were flowing, so at least ARP worked. Now it
> > > does not work anymore.
> >
> > What the 'partner' setup looks like ?
> >
> > ip link
> > ip addr
> > ip ro
>
> 'local' setup too please :)
But here, the remote cleary sends an answer without VLAN tag ;)
Maybe its a tg3 (we had a buggy driver until very recent change), or
tcpdump is not up2date...
^ permalink raw reply
* Re: loopback IP alias breaks tftp?
From: Olaf van der Spek @ 2011-10-10 15:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: Josh Boyer, Joel Sing, Julian Anastasov, netdev, francis.souyri
In-Reply-To: <1318260126.3227.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, Oct 10, 2011 at 5:22 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Isn't that a bad way to work around this issue?
>> It'd require you to duplicate your IP config for every daemon that
>> listens on UDP interfaces.
>> What about IP addresses that are added/deleted after the daemon is launchad?
>>
>> Olaf
>
> Thats a pretty common problem, even prior to discussed commit.
>
> If you take a look at common UDP daemons, they have to setup a listener
> for each IP address, OR use the correct API ( setsockopt(fd, IPPROTO_IP,
> &on, sizeof(on)) and handle IP_PKTINFO ancillary message)
Only the latter solution seems right.
Olaf
^ permalink raw reply
* Re: e100 + VLANs?
From: David Lamparter @ 2011-10-10 15:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Lamparter, Michael Tokarev, jeffrey.t.kirsher, netdev
In-Reply-To: <1318260235.3227.5.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, Oct 10, 2011 at 05:23:55PM +0200, Eric Dumazet wrote:
> Le lundi 10 octobre 2011 à 17:13 +0200, David Lamparter a écrit :
> > On Mon, Oct 10, 2011 at 05:05:52PM +0200, Eric Dumazet wrote:
> > > > When pinging this NIC from another machine over VLAN5, I see
> > > > ARP packets coming to it, gets recognized and replies going
> > > > back, all on vlan 5. But on the other side, replies comes
> > > > WITHOUT a VLAN tag!
> > > >
> > > > From this NIC's point of view, capturing on whole ethX:
> > > >
> > > > 00:1f:c6:ef:e5:1b > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.48.11.2 tell 10.48.11.1, length 42
> > > > 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.48.11.2 is-at 00:90:27:30:6d:1c, length 28
> > > >
> > > > From the partner point of view, also on whole ethX:
> > > >
> > > > 00:1f:c6:ef:e5:1b > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.48.11.2 tell 10.48.11.1, length 28
> > > > 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.48.11.2 is-at 00:90:27:30:6d:1c, length 46
> > > >
> > > > So, the tag gets eaten somewhere along the way... ;)
> >
> > Hmm. Looks like broken VLAN TX offload, but the driver doesn't even
> > implement VLAN offload. Maybe it's broken in its non-implementation...
> >
> > Your "partner" is a known-good setup and can be assumed to be working
> > correctly? This is over a crossover cable, no evil switches involved?
> >
> > > > And I can't really recreate the situation which I had - I know
> > > > some packets were flowing, so at least ARP worked. Now it
> > > > does not work anymore.
> > >
> > > What the 'partner' setup looks like ?
> > >
> > > ip link
> > > ip addr
> > > ip ro
> >
> > 'local' setup too please :)
>
> But here, the remote cleary sends an answer without VLAN tag ;)
Huh? The remote sends the ARP request to ff:f..f:ff, which has a VLAN
tag in both dumps - but the packet sent from the e100 only has a tag in
its own tcpdump... so it might pretty much wind up on the wire without a
tag due to some TX bug...
-David
^ permalink raw reply
* Re: e100 + VLANs?
From: Eric Dumazet @ 2011-10-10 15:50 UTC (permalink / raw)
To: David Lamparter; +Cc: Michael Tokarev, jeffrey.t.kirsher, netdev
In-Reply-To: <20111010152845.GC3260852@jupiter.n2.diac24.net>
Le lundi 10 octobre 2011 à 17:28 +0200, David Lamparter a écrit :
> Huh? The remote sends the ARP request to ff:f..f:ff, which has a VLAN
> tag in both dumps - but the packet sent from the e100 only has a tag in
> its own tcpdump... so it might pretty much wind up on the wire without a
> tag due to some TX bug...
>
I read the reverse from the mail.
But this is probably the reverse :
MAC address of partner : 00:1f:c6:ef:e5:1b (ASUSTek prefix)
MAC address of e100 : 00:90:27:30:6d:1c
^ permalink raw reply
* Re: [PATCH 1/9] mm: add a "struct subpage" type containing a page, offset and length
From: Christoph Hellwig @ 2011-10-10 15:55 UTC (permalink / raw)
To: Ian Campbell; +Cc: netdev, linux-mm
In-Reply-To: <1318245101-16890-1-git-send-email-ian.campbell@citrix.com>
On Mon, Oct 10, 2011 at 12:11:33PM +0100, Ian Campbell wrote:
> A few network drivers currently use skb_frag_struct for this purpose but I have
> patches which add additional fields and semantics there which these other uses
> do not want.
>
> A structure for reference sub-page regions seems like a generally useful thing
> so do so instead of adding a network subsystem specific structure.
Subpage seems like a fairly bad name. page_frag would fit into the
scheme used in a few other places.
The brings back the discussion of unifying the various incarnations we
have of this (biovec, skb frag and there were a few more at times),
but IIRC one of the sticking points back then was that one offset
insistet in 32-bit offset/len and the other on 16-bit.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] af_packet: tpacket_destruct_skb, deref skb after BUG_ON assertion
From: Eric Dumazet @ 2011-10-10 16:06 UTC (permalink / raw)
To: danborkmann; +Cc: David S. Miller, netdev
In-Reply-To: <20111010100203.15066m7nvqod58cb@webmail.your-server.de>
Le lundi 10 octobre 2011 à 10:02 +0200, danborkmann@iogearbox.net a
écrit :
> Thanks, you're absolutely right! Here's the trivial patch:
>
> af_packet: removed unnecessary BUG_ON assertion in tpacket_destruct_skb
>
OK but a proper title should be
[PATCH] af_packet: remove unnecessary BUG_ON() in tpacket_destruct_skb
> If skb is NULL, then stack trace is thrown on anyway on dereference.
> Therefore,
> the stack trace triggered by BUG_ON is duplicate.
>
> Signed-off-by: Daniel Borkmann <danborkmann@googlemail.com>
>
missing "---" separator
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index fabb4fa..886ae50 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1170,8 +1170,6 @@ static void tpacket_destruct_skb(struct sk_buff *skb)
> struct packet_sock *po = pkt_sk(skb->sk);
> void *ph;
>
> - BUG_ON(skb == NULL);
> -
> if (likely(po->tx_ring.pg_vec)) {
> ph = skb_shinfo(skb)->destructor_arg;
> BUG_ON(__packet_get_status(po, ph) != TP_STATUS_SENDING);
>
>
Please send a complete new mail without any history.
^ permalink raw reply
* Re: [PATCH 1/9] mm: add a "struct subpage" type containing a page, offset and length
From: Ian Campbell @ 2011-10-10 16:10 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: netdev@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <20111010155557.GA15503@infradead.org>
On Mon, 2011-10-10 at 16:55 +0100, Christoph Hellwig wrote:
> On Mon, Oct 10, 2011 at 12:11:33PM +0100, Ian Campbell wrote:
> > A few network drivers currently use skb_frag_struct for this purpose but I have
> > patches which add additional fields and semantics there which these other uses
> > do not want.
> >
> > A structure for reference sub-page regions seems like a generally useful thing
> > so do so instead of adding a network subsystem specific structure.
>
> Subpage seems like a fairly bad name. page_frag would fit into the
> scheme used in a few other places.
ok.
> The brings back the discussion of unifying the various incarnations we
> have of this (biovec, skb frag and there were a few more at times),
> but IIRC one of the sticking points back then was that one offset
> insistet in 32-bit offset/len and the other on 16-bit.
This version sizes the fields according to page size, was there
somewhere which wanted to use an offset > PAGE_SIZE (or size > PAGE_SIZE
for that matter). That would be pretty odd and/or not really a candidate
for using this datastructure?
Ian.
^ permalink raw reply
* Re: [net-next 02/11] igb: Use node specific allocations for the q_vectors and rings
From: Alexander Duyck @ 2011-10-10 16:15 UTC (permalink / raw)
To: David Miller; +Cc: jeffrey.t.kirsher, netdev, gospo, sassmann
In-Reply-To: <20111008.155158.566839176815794249.davem@davemloft.net>
On 10/08/2011 12:51 PM, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Fri, 7 Oct 2011 23:47:32 -0700
>
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> This change is meant to update the ring and vector allocations so that they
>> are per node instead of allocating everything on the node that
>> ifconfig/modprobe is called on. By doing this we can cut down
>> significantly on cross node traffic.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> adapter->node seems superfluous.
>
> It's always "-1" when we enter the allocation functions, and we
> always restore it to it's original value upon exit from such
> functions.
>
> Just get rid of it and use a local variable in these functions
> to keep track of the current allocation node.
>
> Also, what ensures that MSI-X interrupts are targetted to a cpu
> on the the node where you've made these allocations? I was
> pretty sure Ben Hutchings added infrastructure that's usable
> to ensure this, but I can't see where you're using it.
Actually the main reason for having adapter->node is because in our
out-of-tree driver we end up using it as a module parameter in the event
that someone is running in single queue mode and wants to split up the
ports between nodes. As such I would prefer to keep the parameter
around and just default it to -1 as I am currently doing. However if it
must go I guess I can work around that sync-up issue.
In this case we don't have any guarantee other than the fact that most
people when trying to get performance will arrange their IRQs in a round
robin fashion. However this approach is still preferred over just
allocating all of the rings on one node and incurring the possible
overhead for all of the access being primarily on a single node. The
igb implementation doesn't have the code in place yet for the irq
affinity hints. It is one of the few things remaining for me to sync up
between igb and ixgbe, however it is on my list of things to do.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 1/9] mm: add a "struct subpage" type containing a page, offset and length
From: Christoph Hellwig @ 2011-10-10 16:19 UTC (permalink / raw)
To: Ian Campbell
Cc: Christoph Hellwig, netdev@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <1318263059.21903.462.camel@zakaz.uk.xensource.com>
On Mon, Oct 10, 2011 at 05:10:59PM +0100, Ian Campbell wrote:
> This version sizes the fields according to page size, was there
> somewhere which wanted to use an offset > PAGE_SIZE (or size > PAGE_SIZE
> for that matter). That would be pretty odd and/or not really a candidate
> for using this datastructure?
I wasn't ever part of the fight myself and only vaguely remember it.
Try to get linux-kernel and Jens onto the Cc list to at least have the
major stakeholders informed.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] net: ipv6: Allow netlink to set IPv6 address scope
From: Brian Haley @ 2011-10-10 16:16 UTC (permalink / raw)
To: Lorenzo Colitti; +Cc: maze, yoshfuji, netdev, c
In-Reply-To: <20111005201559.E544016A599@drone1.mtv.corp.google.com>
On 10/05/2011 04:15 PM, Lorenzo Colitti wrote:
> net: ipv6: Allow netlink to set IPv6 address scope
>
> Currently, userspace cannot specify the scope of IPv6
> addresses when creating or modifying them. Instead, the
> scope is automatically determined from the address itself.
> In IPv4, userspace can set whatever scope it likes.
>
> Allow userspace to specify the scope of IPv6 addresses in
> a backwards-compatible way: if the scope passed in is zero,
> use the old behaviour of automatically determining the
> scope based on the address.
>
> Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Hi Lorenzo,
I remember someone proposing a similar patch before and it was not accepted, do
you have a use case for doing this? It just seems like it will cause problems.
Also, there are other parts of the kernel (NFS, SCTP, IPv6 multicast) that are
still calling ipv6_addr_scope() on a plain address - won't those be broken since
they'll return the correct, RFC-implied scope?
-Brian
^ permalink raw reply
* Re: [net-next 02/11] igb: Use node specific allocations for the q_vectors and rings
From: Alexander Duyck @ 2011-10-10 16:25 UTC (permalink / raw)
To: Andi Kleen; +Cc: Jeff Kirsher, davem, netdev, gospo, sassmann
In-Reply-To: <m21uum2g28.fsf@firstfloor.org>
On 10/09/2011 11:08 AM, Andi Kleen wrote:
> Jeff Kirsher <jeffrey.t.kirsher@intel.com> writes:
>>
>> for (i = 0; i < adapter->num_tx_queues; i++) {
>> - ring = kzalloc(sizeof(struct igb_ring), GFP_KERNEL);
>> + if (orig_node == -1) {
>> + int cur_node = next_online_node(adapter->node);
>> + if (cur_node == MAX_NUMNODES)
>> + cur_node = first_online_node;
>
> RR seems quite arbitrary. Who guarantees those nodes have any
> relationship with the CPUs submitting on those queues? Or the node
> the device is on.
>
> Anyways if it's a good idea probably need to add a
> dma_alloc_coherent_node() too
>
> -Andi
>
The RR configuration is somewhat arbitrary. However it is still better
than dumping everyting on a single node, and it works with the
configuration when the rings numbers line up with the CPU numbers since
normally the CPUs are RR on the nodes. From what I have seen it does
work quite well and it prevents almost all cross-node memory accesses
when running a routing workload.
I was thinking along the same lines for dma_alloc_coherent_node as well.
I've been meaning to get to it but I just haven't had the time. I'm
intentionally holding off on the ixgbe version of these patches until I
get the time to write up such a function. At which time I was going to
write up a patch to convert igb over to it.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 1/9] mm: add a "struct subpage" type containing a page, offset and length
From: Ian Campbell @ 2011-10-10 16:27 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: linux-mm@kvack.org, linux-kernel, Jens Axboe, Christoph Hellwig
In-Reply-To: <1318245101-16890-1-git-send-email-ian.campbell@citrix.com>
(reposting including LKML to catch other potential users)
Is this structure of any use to unify other instances of a similar
tuple, e.g. biovec, pagefrag etc?
Ian.
On Mon, 2011-10-10 at 12:11 +0100, Ian Campbell wrote:
> A few network drivers currently use skb_frag_struct for this purpose but I have
> patches which add additional fields and semantics there which these other uses
> do not want.
>
> A structure for reference sub-page regions seems like a generally useful thing
> so do so instead of adding a network subsystem specific structure.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: linux-mm@kvack.org
> ---
> include/linux/mm_types.h | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 774b895..dc1d103 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -135,6 +135,17 @@ struct page {
> #endif
> ;
>
> +struct subpage {
> + struct page *page;
> +#if (BITS_PER_LONG > 32) || (PAGE_SIZE >= 65536)
> + __u32 page_offset;
> + __u32 size;
> +#else
> + __u16 page_offset;
> + __u16 size;
> +#endif
> +};
> +
> typedef unsigned long __nocast vm_flags_t;
>
> /*
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next] macvlan: handle fragmented multicast frames
From: Ben Greear @ 2011-10-10 16:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1317932911.3457.31.camel@edumazet-laptop>
On 10/06/2011 01:28 PM, Eric Dumazet wrote:
> Le mercredi 05 octobre 2011 à 15:35 -0700, Ben Greear a écrit :
>
>> If someone wants to cook up macvlan-ip-defrag patch I'll be happy
>> to test it. But, as far as I can tell, this problem can happen on
>> any two interfaces. The reason that some of mine work (.1q vlans)
>> and macvlan didn't is probably because those were separated by
>> some virtual network links that imparted extra delay...so the
>> vlan consumed all its fragments and passed the complete pkt up
>> the stack before the mac-vlan ever saw the initial frame.
>>
>> With this in mind, it seems that using multiple udp multicast
>> sockets bound to specific devices is fundamentally broken for
>> fragmented packets.
>>
>> I have no pressing need for this feature, so now that I better understand
>> the problem I can just document it and move on to other things.
>>
>> Thanks for all the help.
>>
>
> Please test following patch (note I had no time to test it, sorry !)
>
> Based on net-next tree, might apply on 3.0 kernel...
>
> [PATCH net-next] macvlan: handle fragmented multicast frames
>
> Fragmented multicast frames are delivered to a single macvlan port,
> because ip defrag logic considers other samples are redundant.
>
> Implement a defrag step before trying to send the multicast frame.
I applied this to Linus' top-of-tree this morning and it does appear
to fix the problem for mac-vlans.
I do see this error, but I doubt it has anything to do with your
patch:
device eth0 entered promiscuous mode
device rddVR10 entered promiscuous mode
ADDRCONF(NETDEV_CHANGE): rddVR1b: link becomes ready
================================================
[ BUG: lock held when returning to user space! ]
------------------------------------------------
ip/3452 is leaving the kernel with locks still held!
1 lock held by ip/3452:
#0: (rcu_read_lock){.+.+..}, at: [<f8c5336f>] rcu_read_lock+0x0/0x26 [ipv6]
ADDRCONF(NETDEV_CHANGE): rddVR4b: link becomes ready
ADDRCONF(NETDEV_CHANGE): rddVR5b: link becomes ready
I have no idea why it doesn't print out a more useful stack
trace. It seems repeatable (2 of 2 reboots so far). I'm
configuring a pretty complex virtual network, with veth devices,
xorp instances running ipv4 and ipv6 routing protocols, etc.
This is a clean upstream kernel with no outside patches aside from your
own.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [net-next 02/11] igb: Use node specific allocations for the q_vectors and rings
From: Andi Kleen @ 2011-10-10 16:32 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Andi Kleen, Jeff Kirsher, davem, netdev, gospo, sassmann
In-Reply-To: <4E931C61.7040204@intel.com>
> The RR configuration is somewhat arbitrary. However it is still better
> than dumping everyting on a single node, and it works with the
> configuration when the rings numbers line up with the CPU numbers since
> normally the CPUs are RR on the nodes. From what I have seen it does
> work quite well and it prevents almost all cross-node memory accesses
> when running a routing workload.
Ok so it's optimized for one specific workload. I'm sure you'll
find some other workload where it doesn't work out.
I suppose it's hard to get right in the general case, but best
would be if ethtool had a nice and easy interface to set it at least.
However one disadvantage of that patch over the existing state of the
art (numactl modprobe ...) is that there's no way to override the placement
now. So if you do the forced RR I think you need the ethtool part too,
or at least some parameter to turn it off.
-Andi
^ permalink raw reply
* Re: [PATCH net] mscan: zero accidentally copied register content
From: Oliver Hartkopp @ 2011-10-10 16:38 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Andre Naujoks, Wolfram Sang, Linux Netdev List
In-Reply-To: <4E8DF24E.5030606@grandegger.com>
On 10/06/11 20:24, Wolfgang Grandegger wrote:
> Well, copying just the relevant bytes seem much more straight-forward
> than removing accidentally copied bytes later-on. You do not need to
> care about little endian. The MSCAN is only available on PowerPC SOCs,
> which are big endian.
>
> I'm going to test and post a patch tomorrow.
Thanks.
My patch is then superseded by this one
"mscan: too much data copied to CAN frame due to 16 bit accesses"
http://patchwork.ozlabs.org/patch/118364/
Tnx,
Oliver
^ permalink raw reply
* Re: [PATCH net-next] macvlan: handle fragmented multicast frames
From: Eric Dumazet @ 2011-10-10 16:41 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4E931CEC.5050404@candelatech.com>
Le lundi 10 octobre 2011 à 09:27 -0700, Ben Greear a écrit :
> I applied this to Linus' top-of-tree this morning and it does appear
> to fix the problem for mac-vlans.
>
Thanks for testing
> I do see this error, but I doubt it has anything to do with your
> patch:
>
> device eth0 entered promiscuous mode
> device rddVR10 entered promiscuous mode
> ADDRCONF(NETDEV_CHANGE): rddVR1b: link becomes ready
>
> ================================================
> [ BUG: lock held when returning to user space! ]
> ------------------------------------------------
> ip/3452 is leaving the kernel with locks still held!
> 1 lock held by ip/3452:
> #0: (rcu_read_lock){.+.+..}, at: [<f8c5336f>] rcu_read_lock+0x0/0x26 [ipv6]
> ADDRCONF(NETDEV_CHANGE): rddVR4b: link becomes ready
> ADDRCONF(NETDEV_CHANGE): rddVR5b: link becomes ready
>
>
> I have no idea why it doesn't print out a more useful stack
> trace. It seems repeatable (2 of 2 reboots so far). I'm
> configuring a pretty complex virtual network, with veth devices,
> xorp instances running ipv4 and ipv6 routing protocols, etc.
>
Do you have LOCKDEP enabled ?
> This is a clean upstream kernel with no outside patches aside from your
> own.
Hmm, it seems we have an rcu_read_unlock() missing...
Any idea what was done by this "ip" command ?
^ permalink raw reply
* [PATCH] mlx4_en: fix endianness with blue frame support
From: Thadeu Lima de Souza Cascardo @ 2011-10-10 16:42 UTC (permalink / raw)
To: netdev
Cc: linuxppc-dev, Thadeu Lima de Souza Cascardo, Eli Cohen,
Yevgeny Petrilin, Benjamin Herrenschmidt
In-Reply-To: <1318231920.29415.404.camel@pasglop>
The doorbell register was being unconditionally swapped. In x86, that
meant it was being swapped to BE and written to the descriptor and to
memory, depending on the case of blue frame support or writing to
doorbell register. On PPC, this meant it was being swapped to LE and
then swapped back to BE while writing to the register. But in the blue
frame case, it was being written as LE to the descriptor.
The fix is not to swap doorbell unconditionally, write it to the
register as BE and convert it to BE when writing it to the descriptor.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Reported-by: Richard Hendrickson <richhend@us.ibm.com>
Cc: Eli Cohen <eli@dev.mellanox.co.il>
Cc: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/mlx4/en_tx.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/mlx4/en_tx.c b/drivers/net/mlx4/en_tx.c
index 6e03de0..f76ab6b 100644
--- a/drivers/net/mlx4/en_tx.c
+++ b/drivers/net/mlx4/en_tx.c
@@ -172,7 +172,7 @@ int mlx4_en_activate_tx_ring(struct mlx4_en_priv *priv,
memset(ring->buf, 0, ring->buf_size);
ring->qp_state = MLX4_QP_STATE_RST;
- ring->doorbell_qpn = swab32(ring->qp.qpn << 8);
+ ring->doorbell_qpn = ring->qp.qpn << 8;
mlx4_en_fill_qp_context(priv, ring->size, ring->stride, 1, 0, ring->qpn,
ring->cqn, &ring->context);
@@ -791,7 +791,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
skb_orphan(skb);
if (ring->bf_enabled && desc_size <= MAX_BF && !bounce && !vlan_tag) {
- *(u32 *) (&tx_desc->ctrl.vlan_tag) |= ring->doorbell_qpn;
+ *(__be32 *) (&tx_desc->ctrl.vlan_tag) |= cpu_to_be32(ring->doorbell_qpn);
op_own |= htonl((bf_index & 0xffff) << 8);
/* Ensure new descirptor hits memory
* before setting ownership of this descriptor to HW */
@@ -812,7 +812,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
wmb();
tx_desc->ctrl.owner_opcode = op_own;
wmb();
- writel(ring->doorbell_qpn, ring->bf.uar->map + MLX4_SEND_DOORBELL);
+ iowrite32be(ring->doorbell_qpn, ring->bf.uar->map + MLX4_SEND_DOORBELL);
}
/* Poll CQ here */
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] mlx4_en: fix endianness with blue frame support
From: Thadeu Lima de Souza Cascardo @ 2011-10-10 16:46 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, Eli Cohen, Yevgeny Petrilin, Benjamin Herrenschmidt
In-Reply-To: <1318264943-10009-1-git-send-email-cascardo@linux.vnet.ibm.com>
On Mon, Oct 10, 2011 at 01:42:23PM -0300, Thadeu Lima de Souza Cascardo wrote:
> The doorbell register was being unconditionally swapped. In x86, that
> meant it was being swapped to BE and written to the descriptor and to
> memory, depending on the case of blue frame support or writing to
> doorbell register. On PPC, this meant it was being swapped to LE and
> then swapped back to BE while writing to the register. But in the blue
> frame case, it was being written as LE to the descriptor.
>
> The fix is not to swap doorbell unconditionally, write it to the
> register as BE and convert it to BE when writing it to the descriptor.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
> Reported-by: Richard Hendrickson <richhend@us.ibm.com>
> Cc: Eli Cohen <eli@dev.mellanox.co.il>
> Cc: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
So I tested this patch and it works for me. Thanks Ben and Eli for
finding out the problem with doorbell in the descriptor.
Regards,
Cascardo.
> drivers/net/mlx4/en_tx.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/mlx4/en_tx.c b/drivers/net/mlx4/en_tx.c
> index 6e03de0..f76ab6b 100644
> --- a/drivers/net/mlx4/en_tx.c
> +++ b/drivers/net/mlx4/en_tx.c
> @@ -172,7 +172,7 @@ int mlx4_en_activate_tx_ring(struct mlx4_en_priv *priv,
> memset(ring->buf, 0, ring->buf_size);
>
> ring->qp_state = MLX4_QP_STATE_RST;
> - ring->doorbell_qpn = swab32(ring->qp.qpn << 8);
> + ring->doorbell_qpn = ring->qp.qpn << 8;
>
> mlx4_en_fill_qp_context(priv, ring->size, ring->stride, 1, 0, ring->qpn,
> ring->cqn, &ring->context);
> @@ -791,7 +791,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
> skb_orphan(skb);
>
> if (ring->bf_enabled && desc_size <= MAX_BF && !bounce && !vlan_tag) {
> - *(u32 *) (&tx_desc->ctrl.vlan_tag) |= ring->doorbell_qpn;
> + *(__be32 *) (&tx_desc->ctrl.vlan_tag) |= cpu_to_be32(ring->doorbell_qpn);
> op_own |= htonl((bf_index & 0xffff) << 8);
> /* Ensure new descirptor hits memory
> * before setting ownership of this descriptor to HW */
> @@ -812,7 +812,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
> wmb();
> tx_desc->ctrl.owner_opcode = op_own;
> wmb();
> - writel(ring->doorbell_qpn, ring->bf.uar->map + MLX4_SEND_DOORBELL);
> + iowrite32be(ring->doorbell_qpn, ring->bf.uar->map + MLX4_SEND_DOORBELL);
> }
>
> /* Poll CQ here */
> --
> 1.7.4.4
>
^ 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