* Re: [PATCH] xfrm: Add SHA384 and SHA512 HMAC authentication algorithms to XFRM
From: Herbert Xu @ 2009-11-25 12:11 UTC (permalink / raw)
To: Martin Willi; +Cc: linux-crypto, netdev, David S. Miller
In-Reply-To: <1259146719-16359-1-git-send-email-martin@strongswan.org>
On Wed, Nov 25, 2009 at 11:58:39AM +0100, Martin Willi wrote:
> These algorithms use a truncation of 192/256 bits, as specified
> in RFC4868.
>
> Signed-off-by: Martin Willi <martin@strongswan.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/3] xfrm: Custom truncation lengths for authentication algorithms
From: Herbert Xu @ 2009-11-25 12:10 UTC (permalink / raw)
To: Martin Willi; +Cc: linux-crypto, netdev, David S. Miller
In-Reply-To: <cover.1259142145.git.martin@strongswan.org>
On Wed, Nov 25, 2009 at 11:29:50AM +0100, Martin Willi wrote:
> The following patchset adds support for defining truncation lengths
> for authentication algorithms in userspace. The main purpose for this
> is to support SHA256 in IPsec using the standardized 128 bit
> instead of the currently used 96 bit truncation.
>
> Martin Willi (3):
> xfrm: Define new XFRM netlink auth attribute with specified
> truncation bits
> xfrm: Store aalg in xfrm_state with a user specified truncation
> length
> xfrm: Use the user specified truncation length in ESP and AH
Looks great to me. Thanks Martin!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints
From: Andi Kleen @ 2009-11-25 11:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, David Miller, peter.p.waskiewicz.jr, peterz, arjan,
yong.zhang0, linux-kernel, arjan, netdev
In-Reply-To: <4B0D1667.8050506@gmail.com>
On Wed, Nov 25, 2009 at 12:35:03PM +0100, Eric Dumazet wrote:
> > You seem to only have 8 CPUs (one socket) Normally a dual socket nehalem
> > should have 16 with HyperThreading enabled.
> >
> > For some reason the BIOS is not reporting the other CPU.
> >
> > You could double check with acpidmp / iasl -d if that's
> > what the BIOS really reports, but normally it should work.
> >
>
> Good Lord, I had a CONFIG_NR_CPUS=16 in my .config.
That should be enough for a two socket (2S x 4C x 2T) today,
but of course that will eventually change too.
> Changing to to 32 or 64 seems better :)
That looks weird. It should have worked with CONFIG_NR_CPUS==16 too,
because you only have 16 CPUs and the NR_CPUS should affect APIC
ranges etc.
Something still fishy. I would properly report it.
BTW kernel should give some error message in any case when
there are not enough CPUs I guess.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: TCP sockets stalling - help! (long)
From: Ilpo Järvinen @ 2009-11-25 11:48 UTC (permalink / raw)
To: Asdo; +Cc: Netdev, e1000-devel
In-Reply-To: <4B0CB1B8.8030402@shiftmail.org>
On Wed, 25 Nov 2009, Asdo wrote:
> Hi netdev and e1000 people,
>
> I have a weird problem here.
>
> We have a Linux "Storage" server acting as a Samba, SCP and SFTP fileserver.
> All clients are Windows: XP and Vista, 32 and 64 bits. The building has
> gigabit network. We transfer up to many TB at a time.
>
> I have tried from many clients to the same Server and there is always the same
> problem: after hours that a transfer is running the TCP socket suddenly
> stalls: 0 bytes/sec. It doesn't slow down, it stalls suddenly. It never
> disconnects though.
>
> From that moment onward, the TCP socket stays in a stalling condition forever
> (I saw myself at least 10 hours) and both sides see it Established forever.
> This is in case of no other networking activity on the same network card.
> In case of other networking activity someone told me that he did see the
> transfer restart (=continue) by itself (it was an SFTP that time). I think I
> saw this phenomenon myself once during the tcpdump at the bottom of this
> email.
>
> This problem happens on every protocol (Samba, SCP, SFTP) and apparently any
> client (for sure I tested on at least 1 Vista 64bit and 1 XP 32bit).
>
> Also happens in the middle of transferring one file, so not necessarily at
> file change. The files are being pushed from the clients to the linux Server.
>
> The gigabit switch between the machines was changed 2 times (the brands also
> were different) without results.
>
> I was able to obtain apparently reliable nonstop transfer if I performed 6
> simultaneous transfers with Samba from the same client to the same server.
> OTOH with just 1 - 3 simultaneous transfers only all of them will eventually
> stall. Note that with 2 transfers the speed of each one is already smaller
> than the speed of a single transfer (approx 40+40MB/sec vs 60MB/sec) however
> with 6 transfers it's obviously much smaller (approx 6x12MB/sec). The bug
> looks like some kind of a race condition to me.
>
> On Samba another strange fact is that if there are multiple transfers (i.e. 2)
> from the same client to the same server (please note that in this case with
> Samba all transfers pass through the same TCP socket) the two transfers stall
> *independently* one to the other. First after a random time you see one
> stalling, and eventually after another random time also the other one stalls.
> This tells that the socket actually kinda works... I can even stop one stalled
> transfer from the client (the stop operation *works* and gets a reply from the
> Samba server: I see messages sniffing the Ethernet), and start it again and it
> would run, and the TCP socket is always the same when I restart the transfer.
>
> I obtained apparently reliable transfers with Samba if I introduced rate
> limiting on our SMC 8024L2 gigabit switch . Even if the rate limiting was set
> so high (930Mbps) that the transfer speed was actually not influenced, the
> Samba transfer (1 single transfer, not multiple) apparently worked reliably.
> Maybe this helps with the race condition by separating packets better. The
> SFTP protocol hanged anyway though, even on rate limiting, however consider
> that SFTP from windows goes very slow at 15Mbps due to a problem of encryption
> performance of WinSCP, so that one is really way lower than the rate limit and
> its packets might not get separated.
>
> The server is a linux Ubuntu 9.10 with kernel ubuntu 2.6.31-14-server . The
> ethernets are two integrated Intels (I tested both ethernet ports):
> Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller
> (Copper) (rev 01)
> the driver is kernel's e1000
>
> This is the stack trace of server processes (Server side) during an SFTP
> stall:
>
> root 327 [CUT] \_ sshd: myuser [priv]
> 1011 380 [CUT] \_ sshd: myuser
> 1011 382 [CUT] \_ /usr/lib/openssh/sftp-server
>
> root@mystorage:/proc# cat /proc/327/stack (this is sshd)
> [<ffffffff814b428a>] unix_stream_data_wait+0xaa/0x110
> [<ffffffff814b50cd>] unix_stream_recvmsg+0x36d/0x570
> [<ffffffff81426399>] sock_aio_read+0x149/0x150
> [<ffffffff8111e232>] do_sync_read+0xf2/0x130
> [<ffffffff8111e8e1>] vfs_read+0x181/0x1a0
> [<ffffffff8111edec>] sys_read+0x4c/0x80
> [<ffffffff81011fc2>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> root@mystorage:/proc# cat /proc/380/stack (this is the second sshd)
> [<ffffffff8112e644>] poll_schedule_timeout+0x34/0x50
> [<ffffffff8112ef4f>] do_select+0x58f/0x6b0
> [<ffffffff8112f8b5>] core_sys_select+0x185/0x2b0
> [<ffffffff8112fc32>] sys_select+0x42/0x110
> [<ffffffff81011fc2>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> root@mystorage:/proc# cat /proc/382/stack (this is sftp-server)
> [<ffffffff8112e644>] poll_schedule_timeout+0x34/0x50
> [<ffffffff8112ef4f>] do_select+0x58f/0x6b0
> [<ffffffff8112f8b5>] core_sys_select+0x185/0x2b0
> [<ffffffff8112fc32>] sys_select+0x42/0x110
> [<ffffffff81011fc2>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> so everything seems normal, it just seems the socket is waiting for data...
>
> I am really puzzled because... I don't know how the Samba protocol works, but
> for SFTP which I believe is a simple protocol, I believe the client is just
> pushing raw bytes onto a simple TCP socket so it should keep doing that while
> it receives Acks. OTOH if it does not receive Acks the socket would
> disconnect. However in my case during a stall the socket stays Established (I
> checked at BOTH sides!) but the client stops pushing bytes to the server.
> (That's for a stall in the middle of a file on SFTP protocol, which *does*
> happen) How on earth can that be?? (update: see tcpdump below, it might
> explain)
>
> I am also thinking at a hardware problem. The server is running on a Tyan
> mainboard S5396WA2NRF and we had another problem with this computer (mobo?),
> apparently hardware related, with 3ware disk controllers, same problem as this
> guy also running another Tyan:
> http://www.webhostingtalk.com/archive/index.php/t-449670.html
> which I thought might be reconducible to a lost interrupt. Even on a lost
> interrupt I can't understand how to solve the Ack puzzle... this is not a TOE
> network card!
>
> This is what I did try up to now (and didn't help):
> Changed some Samba parameters trying various values (clearly not useful for
> SFTP btw). I ended up with a pretty common configuration, which anyway didn't
> help:
> socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192
> read raw = yes
> write raw = yes
> kernel oplocks = yes
> max xmit = 2048
> getwd cache = yes
>
>
> Changed the following parameters in /proc/sys/net:
> 1 -> 0 > ipv6/bindv6only (for Samba but it was bound already and I couldn't
> reboot. SFTP tests were done in IPv4 though)
> 1 -> 0 > tcp_sack
> 1 -> 0 > tcp_dsack
> 0 -> 1 > tcp_low_latency
> 2 -> 0 > tcp_frto
> cubic -> reno > tcp_congestion_control
> 3 -> 6 > tcp_retries1
> 3 -> 10 > tcp_tso_win_divisor
> 1 -> 0 > tcp_slow_start_after_idle
>
>
> Then I disabled the following offloads using ethtool:
> rx-checksumming on --> off
> tx-checksumming on --> off
> scatter-gather on --> off
> tcp-segmentation-offload: on --> off
> generic-segmentation-offload: on --> off
>
> Nothing helped.
>
>
> This is the SFTP socket when it's running (Server side):
> # cat /proc/net/tcp
> 2: 0F12A8C0:0016 2612A8C0:C0C6 01 00000000:00000000 02:000AB698 00000000
> 0 0 267816 4 ffff88084b1e6180 24 4 1 11 -1
>
> Later on, when it has been stuck for a while:
> # cat /proc/net/tcp
> 2: 0F12A8C0:0016 2612A8C0:C0C6 01 00000000:00000000 02:0002AC6B 00000000
> 0 0 267816 2 ffff88084b1e6180 27 4 1 21 -1
> (numbers reference:
> http://www.mjmwired.net/kernel/Documentation/networking/proc_net_tcp.txt )
>
> as you can see from the last values, the timeout and window have enlarged a
> bit, but nothing dramatic. Apparently they are very similar.
This end has no data to send (the numbers after " 01 ", first one is the
size of the send queue), so it is correct behavior from TCP side.
> This is another SFTP stall after I disabled the offloading via ethtool:
> (different transfer, different socket from above)
> 2: 0F12A8C0:0016 2512A8C0:09BC 01 00000000:00000000 02:000602F4 00000000
> 0 0 5301100 2 ffff88084ac02080 28 4 0 13 -1
> so the values are similar again, apart the ack.pingpong which has become 0
> (something to do with offloading?)
Likewise, no data to send here either at the moment you took this snippet.
> This night I decided to actually tcpdump some traffic at the server side. This
> dump has a chance of being incorrect/misleading because the client I could use
> was already transferring other stuff to the server via Samba. I used SFTP
> protocol for this test but due to the simultaneous Samba transfer I could not
> obtain a long SFTP hangup. The longest hangup I obtained is 1 minute. I hope
> this is really a manifestation of the bug in question, and not a simple
> temporary starvation at server side.
>
> Here is the relevant excerpt:
> 00:54:36.303031 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 12309129:12309229, ack 997119732, win 65535, length 100
> 00:54:36.303216 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 997119732:997120040, ack 12309229, win 64871, length 308
> 00:54:36.303450 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 12309229:12309297, ack 997120040, win 65535, length 68
> 00:54:36.303566 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 997120040:997120228, ack 12309297, win 64803, length 188
> 00:54:36.303645 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 12309297:12309365, ack 997120228, win 65535, length 68
> 00:54:36.304414 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 997120228:997120432, ack 12309365, win 64735, length 204
> 00:54:36.345583 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 997120432, win 65535, length 0 *** PROBLEM IS HERE ***
> 00:55:27.171687 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 12309365:12309425, ack 997120432, win 65535, length 60
> 00:55:27.342682 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 997120432:997120944, ack 12309425, win 64675, length 512
> 00:55:27.342726 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 997120944, win 65535, length 0
> 00:55:27.342775 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [.], seq
> 997120944:997122404, ack 12309425, win 64675, length 1460
> 00:55:27.342787 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 997122404, win 65535, length 0
> 00:55:27.342792 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 997122404:997122612, ack 12309425, win 64675, length 208
> 00:55:27.342795 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 997122612, win 65535, length 0
>
> It seems to me the TCP stack at the Server returns an ack to the client but
> waits 1 minutes before being able to give the further 60 bytes to the client
> (these are application-generated bytes, right?) which are probably needed at
> client-side for the functioning of the SFTP protocol.
> I suspect the SFTP-server application receives the last client data just at
> the end of the minute of delay (at 00:55:27.1something)
> Probably if the dump was made without concomitant Samba activity, the
> sftp-server application would have never received such last client bytes and
> that's why the hangup lasts forever.
> However the TCP socket remains established because the TCP stack works and
> acks are sent properly
> Could this be a good interpretation of the bug?
>
> I don't know what are those 60 bytes though, can you confirm is it a part of
> the SFTP or SSH protocol?
>
> I observed other similar micro-hangups:
> ...
> 00:50:59.210115 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 3346661444, win 65535, length 0
> 00:51:14.137978 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 7757313:7757457, ack 3346661444, win 65535, length 144
> ...
> 00:52:02.495785 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 8612969:8613037, ack 3711382248, win 65535, length 68
> 00:52:02.507752 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 3711382248:3711382452, ack 8613037, win 65399, length 204
> 00:52:02.545585 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 3711382452, win 65535, length 0
> 00:52:14.568489 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 8613037:8613097, ack 3711382452, win 65535, length 60
> 00:52:14.572162 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [P.], seq
> 3711382452:3711382964, ack 8613097, win 65339, length 512
> 00:52:14.572184 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 3711382964, win 65535, length 0
> 00:52:14.572312 IP 192.168.18.37.3418 > 192.168.18.15.22: Flags [.], seq
> 3711382964:3711384424, ack 8613097, win 65339, length 1460
> ...
> 00:55:30.464957 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 1040635920, win 65535, length 0
> 00:55:32.230205 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 12410749:12410809, ack 1040635920, win 65535, length 60
> ...
> 00:55:54.404027 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 1362376840, win 65535, length 0
> 00:56:08.349224 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 13157437:13157497, ack 1362376840, win 65535, length 60
> ...
> 00:56:28.494333 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [.], ack
> 1424904580, win 65535, length 0
> 00:56:31.450352 IP 192.168.18.15.22 > 192.168.18.37.3418: Flags [P.], seq
> 13307333:13307393, ack 1424904580, win 65535, length 60
>
> Update: actually I just found a disk performance problem at Server side so
> that the disks couldn't go faster than 70MB/sec (stripe_cache_size was too low
> and readahead was too low), and I'm thinking if this could be the reason for
> indeed triggering the bug: if there was a starvation of the TCP/IP stack or
> network card driver at the wrong time (because i.e. the CPUs are doing
> something else like accessing the disks), could that prevent the 60-bytes
> packet from ever being transmitted...? (in case of no other incoming ethernet
> packets which can give the TCPIP or e1000 driver a second chance to run)
...I'd next try strace the sftp server to see what it was doing
during the stall.
--
i.
^ permalink raw reply
* Re: [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
From: Michael S. Tsirkin @ 2009-11-25 11:40 UTC (permalink / raw)
To: Rusty Russell
Cc: Shirley Ma, Eric Dumazet, Avi Kivity, netdev, kvm, linux-kernel,
Hollis Blanchard
In-Reply-To: <200911252050.21907.rusty@rustcorp.com.au>
On Wed, Nov 25, 2009 at 08:50:21PM +1030, Rusty Russell wrote:
> On Wed, 25 Nov 2009 07:45:30 pm Michael S. Tsirkin wrote:
> > Hmm, is it really worth it to save a header copy if it's linear? We are
> > going to access it anyway, and it fits into one cacheline nicely. On
> > the other hand we have more code making life harder for compiler and
> > processor.
>
> Not sure: I think there would be many places where it would be useful.
>
> We do a similar thing in the kernel to inspect non-linear packets, and
> it's served us well.
You mean this gives measureable speedup? Okay ...
> Cheers,
> Rusty.
^ permalink raw reply
* Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints
From: Eric Dumazet @ 2009-11-25 11:35 UTC (permalink / raw)
To: Andi Kleen
Cc: David Miller, peter.p.waskiewicz.jr, peterz, arjan, yong.zhang0,
linux-kernel, arjan, netdev
In-Reply-To: <20091125103713.GF29096@one.firstfloor.org>
Andi Kleen a écrit :
> Works here
>> dmesg | grep -i node
>> [ 0.000000] SRAT: PXM 0 -> APIC 0 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 1 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 2 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 3 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 4 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 5 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 6 -> Node 0
>> [ 0.000000] SRAT: PXM 0 -> APIC 7 -> Node 0
>
> You seem to only have 8 CPUs (one socket) Normally a dual socket nehalem
> should have 16 with HyperThreading enabled.
>
> For some reason the BIOS is not reporting the other CPU.
>
> You could double check with acpidmp / iasl -d if that's
> what the BIOS really reports, but normally it should work.
>
Good Lord, I had a CONFIG_NR_CPUS=16 in my .config.
Changing to to 32 or 64 seems better :)
# dmesg | grep -i node
[ 0.000000] SRAT: PXM 0 -> APIC 0 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 1 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 2 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 3 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 4 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 5 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 6 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 7 -> Node 0
[ 0.000000] SRAT: PXM 1 -> APIC 16 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 17 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 18 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 19 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 20 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 21 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 22 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 23 -> Node 1
[ 0.000000] SRAT: Node 0 PXM 0 0-e0000000
[ 0.000000] SRAT: Node 0 PXM 0 100000000-220000000
[ 0.000000] SRAT: Node 1 PXM 1 220000000-420000000
[ 0.000000] Bootmem setup node 0 0000000000000000-0000000220000000
[ 0.000000] NODE_DATA [0000000000001000 - 0000000000005fff]
[ 0.000000] Bootmem setup node 1 0000000220000000-000000041ffff000
[ 0.000000] NODE_DATA [0000000220000000 - 0000000220004fff]
[ 0.000000] [ffffea0000000000-ffffea00087fffff] PMD -> [ffff880028600000-ffff8800305fffff] on node 0
[ 0.000000] [ffffea0008800000-ffffea00107fffff] PMD -> [ffff880220200000-ffff8802281fffff] on node 1
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[5] active PFN ranges
[ 0.000000] On node 0 totalpages: 2094543
[ 0.000000] On node 1 totalpages: 2097151
[ 0.000000] NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:32 nr_node_ids:2
[ 0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=2
[ 0.004830] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.007291] CPU 0/0x0 -> Node 0
[ 0.398106] CPU 1/0x10 -> Node 1
[ 0.557857] CPU 2/0x4 -> Node 0
[ 0.717609] CPU 3/0x14 -> Node 1
[ 0.877359] CPU 4/0x2 -> Node 0
[ 1.037112] CPU 5/0x12 -> Node 1
[ 1.196862] CPU 6/0x6 -> Node 0
[ 1.356614] CPU 7/0x16 -> Node 1
[ 1.516368] CPU 8/0x1 -> Node 0
[ 1.676117] CPU 9/0x11 -> Node 1
[ 1.835867] CPU 10/0x5 -> Node 0
[ 1.995619] CPU 11/0x15 -> Node 1
[ 2.155370] CPU 12/0x3 -> Node 0
[ 2.315122] CPU 13/0x13 -> Node 1
[ 2.474873] CPU 14/0x7 -> Node 0
[ 2.634624] CPU 15/0x17 -> Node 1
Thanks Andi
^ permalink raw reply
* Re: [RFC PATCH 00/10] Remove skb_dma_map/unmap calls
From: Ajit Khaparde @ 2009-11-25 11:30 UTC (permalink / raw)
To: Alexander Duyck; +Cc: mcarlson, mchan, sathyap, subbus, davem, netdev
In-Reply-To: <20091125011111.32704.3009.stgit@gitlad.jf.intel.com>
On 24/11/09 17:20 -0800, Alexander Duyck wrote:
> This patch series removes the skb_dma_map and skb_dma_unmap function calls.
> The reason for this change is because the use of skb_dma_map/unmap can lead
> to serious issues when HW IOMMU is enabled. This is because each mapping
> of the skb with a HW IOMMU enabled results in a new set of DMA mappings.
> This in turn leads to issues when skbs are cloned for uses such as
> bridging or pktgen because each transmitting device will update the skb
> shared info structure resulting in some mappings being overwritten, and others
> being freed multiple times.
If this is the case can the members related to the dma mapping stuff
(skb_shinfo(skb)->dma_maps) be moved out of this shared info structure and
we retain this "good" abstraction provided by this skb_dma_map/unmap api?
>
> I am looking for input specifically on the tg3, be2net, and bnx2 driver
> patches as I am not very familiar with them and I am not certain if
> additional changes are required.
> be2net: remove use of skb_dma_map/unmap
>
> drivers/net/benet/be_main.c | 37 ++++++---
We have pulled the be2net specific patch for testing and review.
We will send an update once done with it.
-Ajit
^ permalink raw reply
* Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints
From: Peter Zijlstra @ 2009-11-25 11:18 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Peter P Waskiewicz Jr, Yong Zhang, linux-kernel@vger.kernel.org,
arjan@linux.jf.intel.com, davem@davemloft.net,
netdev@vger.kernel.org, Jesse Barnes
In-Reply-To: <alpine.LFD.2.00.0911241027140.24119@localhost.localdomain>
While we're dicking about with irq affinities, maybe we ought to
consider cpuset integration as well. There's various folks who want to
use exclusive cpusets to isolate workloads.
^ permalink raw reply
* [PATCH] xfrm: Add SHA384 and SHA512 HMAC authentication algorithms to XFRM
From: Martin Willi @ 2009-11-25 10:58 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
These algorithms use a truncation of 192/256 bits, as specified
in RFC4868.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
net/xfrm/xfrm_algo.c | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index faf54c6..480afda 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -200,6 +200,40 @@ static struct xfrm_algo_desc aalg_list[] = {
}
},
{
+ .name = "hmac(sha384)",
+
+ .uinfo = {
+ .auth = {
+ .icv_truncbits = 192,
+ .icv_fullbits = 384,
+ }
+ },
+
+ .desc = {
+ .sadb_alg_id = SADB_X_AALG_SHA2_384HMAC,
+ .sadb_alg_ivlen = 0,
+ .sadb_alg_minbits = 384,
+ .sadb_alg_maxbits = 384
+ }
+},
+{
+ .name = "hmac(sha512)",
+
+ .uinfo = {
+ .auth = {
+ .icv_truncbits = 256,
+ .icv_fullbits = 512,
+ }
+ },
+
+ .desc = {
+ .sadb_alg_id = SADB_X_AALG_SHA2_512HMAC,
+ .sadb_alg_ivlen = 0,
+ .sadb_alg_minbits = 512,
+ .sadb_alg_maxbits = 512
+ }
+},
+{
.name = "hmac(rmd160)",
.compat = "rmd160",
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] xfrm: Store aalg in xfrm_state with a user specified truncation length
From: Martin Willi @ 2009-11-25 10:29 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
In-Reply-To: <cover.1259142145.git.martin@strongswan.org>
Adding a xfrm_state requires an authentication algorithm specified
either as xfrm_algo or as xfrm_algo_auth with a specific truncation
length. For compatibility, both attributes are dumped to userspace,
and we also accept both attributes, but prefer the new syntax.
If no truncation length is specified, or the authentication algorithm
is specified using xfrm_algo, the truncation length from the algorithm
description in the kernel is used.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
include/net/xfrm.h | 12 ++++-
net/xfrm/xfrm_state.c | 2 +-
net/xfrm/xfrm_user.c | 129 ++++++++++++++++++++++++++++++++++++++++++++++---
3 files changed, 133 insertions(+), 10 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 223e90a..762327d 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -160,7 +160,7 @@ struct xfrm_state
struct xfrm_lifetime_cfg lft;
/* Data for transformer */
- struct xfrm_algo *aalg;
+ struct xfrm_algo_auth *aalg;
struct xfrm_algo *ealg;
struct xfrm_algo *calg;
struct xfrm_algo_aead *aead;
@@ -1541,12 +1541,22 @@ static inline int xfrm_alg_len(struct xfrm_algo *alg)
return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
}
+static inline int xfrm_alg_auth_len(struct xfrm_algo_auth *alg)
+{
+ return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
+}
+
#ifdef CONFIG_XFRM_MIGRATE
static inline struct xfrm_algo *xfrm_algo_clone(struct xfrm_algo *orig)
{
return kmemdup(orig, xfrm_alg_len(orig), GFP_KERNEL);
}
+static inline struct xfrm_algo_auth *xfrm_algo_auth_clone(struct xfrm_algo_auth *orig)
+{
+ return kmemdup(orig, xfrm_alg_auth_len(orig), GFP_KERNEL);
+}
+
static inline void xfrm_states_put(struct xfrm_state **states, int n)
{
int i;
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index f2f7c63..67121ce 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1110,7 +1110,7 @@ static struct xfrm_state *xfrm_state_clone(struct xfrm_state *orig, int *errp)
x->props.saddr = orig->props.saddr;
if (orig->aalg) {
- x->aalg = xfrm_algo_clone(orig->aalg);
+ x->aalg = xfrm_algo_auth_clone(orig->aalg);
if (!x->aalg)
goto error;
}
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index b95a2d6..fb42d77 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -62,6 +62,22 @@ static int verify_one_alg(struct nlattr **attrs, enum xfrm_attr_type_t type)
return 0;
}
+static int verify_auth_trunc(struct nlattr **attrs)
+{
+ struct nlattr *rt = attrs[XFRMA_ALG_AUTH_TRUNC];
+ struct xfrm_algo_auth *algp;
+
+ if (!rt)
+ return 0;
+
+ algp = nla_data(rt);
+ if (nla_len(rt) < xfrm_alg_auth_len(algp))
+ return -EINVAL;
+
+ algp->alg_name[CRYPTO_MAX_ALG_NAME - 1] = '\0';
+ return 0;
+}
+
static int verify_aead(struct nlattr **attrs)
{
struct nlattr *rt = attrs[XFRMA_ALG_AEAD];
@@ -128,7 +144,8 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
err = -EINVAL;
switch (p->id.proto) {
case IPPROTO_AH:
- if (!attrs[XFRMA_ALG_AUTH] ||
+ if ((!attrs[XFRMA_ALG_AUTH] &&
+ !attrs[XFRMA_ALG_AUTH_TRUNC]) ||
attrs[XFRMA_ALG_AEAD] ||
attrs[XFRMA_ALG_CRYPT] ||
attrs[XFRMA_ALG_COMP])
@@ -139,10 +156,12 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
if (attrs[XFRMA_ALG_COMP])
goto out;
if (!attrs[XFRMA_ALG_AUTH] &&
+ !attrs[XFRMA_ALG_AUTH_TRUNC] &&
!attrs[XFRMA_ALG_CRYPT] &&
!attrs[XFRMA_ALG_AEAD])
goto out;
if ((attrs[XFRMA_ALG_AUTH] ||
+ attrs[XFRMA_ALG_AUTH_TRUNC] ||
attrs[XFRMA_ALG_CRYPT]) &&
attrs[XFRMA_ALG_AEAD])
goto out;
@@ -152,6 +171,7 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
if (!attrs[XFRMA_ALG_COMP] ||
attrs[XFRMA_ALG_AEAD] ||
attrs[XFRMA_ALG_AUTH] ||
+ attrs[XFRMA_ALG_AUTH_TRUNC] ||
attrs[XFRMA_ALG_CRYPT])
goto out;
break;
@@ -161,6 +181,7 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
case IPPROTO_ROUTING:
if (attrs[XFRMA_ALG_COMP] ||
attrs[XFRMA_ALG_AUTH] ||
+ attrs[XFRMA_ALG_AUTH_TRUNC] ||
attrs[XFRMA_ALG_AEAD] ||
attrs[XFRMA_ALG_CRYPT] ||
attrs[XFRMA_ENCAP] ||
@@ -176,6 +197,8 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
if ((err = verify_aead(attrs)))
goto out;
+ if ((err = verify_auth_trunc(attrs)))
+ goto out;
if ((err = verify_one_alg(attrs, XFRMA_ALG_AUTH)))
goto out;
if ((err = verify_one_alg(attrs, XFRMA_ALG_CRYPT)))
@@ -229,6 +252,66 @@ static int attach_one_algo(struct xfrm_algo **algpp, u8 *props,
return 0;
}
+static int attach_auth(struct xfrm_algo_auth **algpp, u8 *props,
+ struct nlattr *rta)
+{
+ struct xfrm_algo *ualg;
+ struct xfrm_algo_auth *p;
+ struct xfrm_algo_desc *algo;
+
+ if (!rta)
+ return 0;
+
+ ualg = nla_data(rta);
+
+ algo = xfrm_aalg_get_byname(ualg->alg_name, 1);
+ if (!algo)
+ return -ENOSYS;
+ *props = algo->desc.sadb_alg_id;
+
+ p = kmalloc(sizeof(*p) + (ualg->alg_key_len + 7) / 8, GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ strcpy(p->alg_name, algo->name);
+ p->alg_key_len = ualg->alg_key_len;
+ p->alg_trunc_len = algo->uinfo.auth.icv_truncbits;
+ memcpy(p->alg_key, ualg->alg_key, (ualg->alg_key_len + 7) / 8);
+
+ *algpp = p;
+ return 0;
+}
+
+static int attach_auth_trunc(struct xfrm_algo_auth **algpp, u8 *props,
+ struct nlattr *rta)
+{
+ struct xfrm_algo_auth *p, *ualg;
+ struct xfrm_algo_desc *algo;
+
+ if (!rta)
+ return 0;
+
+ ualg = nla_data(rta);
+
+ algo = xfrm_aalg_get_byname(ualg->alg_name, 1);
+ if (!algo)
+ return -ENOSYS;
+ if (ualg->alg_trunc_len > algo->uinfo.auth.icv_fullbits)
+ return -EINVAL;
+ *props = algo->desc.sadb_alg_id;
+
+ p = kmemdup(ualg, xfrm_alg_auth_len(ualg), GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ strcpy(p->alg_name, algo->name);
+ if (!p->alg_trunc_len)
+ p->alg_trunc_len = algo->uinfo.auth.icv_truncbits;
+
+ *algpp = p;
+ return 0;
+}
+
static int attach_aead(struct xfrm_algo_aead **algpp, u8 *props,
struct nlattr *rta)
{
@@ -332,10 +415,14 @@ static struct xfrm_state *xfrm_state_construct(struct net *net,
if ((err = attach_aead(&x->aead, &x->props.ealgo,
attrs[XFRMA_ALG_AEAD])))
goto error;
- if ((err = attach_one_algo(&x->aalg, &x->props.aalgo,
- xfrm_aalg_get_byname,
- attrs[XFRMA_ALG_AUTH])))
+ if ((err = attach_auth_trunc(&x->aalg, &x->props.aalgo,
+ attrs[XFRMA_ALG_AUTH_TRUNC])))
goto error;
+ if (!x->props.aalgo) {
+ if ((err = attach_auth(&x->aalg, &x->props.aalgo,
+ attrs[XFRMA_ALG_AUTH])))
+ goto error;
+ }
if ((err = attach_one_algo(&x->ealg, &x->props.ealgo,
xfrm_ealg_get_byname,
attrs[XFRMA_ALG_CRYPT])))
@@ -548,6 +635,24 @@ static int copy_sec_ctx(struct xfrm_sec_ctx *s, struct sk_buff *skb)
return 0;
}
+static int copy_to_user_auth(struct xfrm_algo_auth *auth, struct sk_buff *skb)
+{
+ struct xfrm_algo *algo;
+ struct nlattr *nla;
+
+ nla = nla_reserve(skb, XFRMA_ALG_AUTH,
+ sizeof(*algo) + (auth->alg_key_len + 7) / 8);
+ if (!nla)
+ return -EMSGSIZE;
+
+ algo = nla_data(nla);
+ strcpy(algo->alg_name, auth->alg_name);
+ memcpy(algo->alg_key, auth->alg_key, (auth->alg_key_len + 7) / 8);
+ algo->alg_key_len = auth->alg_key_len;
+
+ return 0;
+}
+
/* Don't change this without updating xfrm_sa_len! */
static int copy_to_user_state_extra(struct xfrm_state *x,
struct xfrm_usersa_info *p,
@@ -563,8 +668,13 @@ static int copy_to_user_state_extra(struct xfrm_state *x,
if (x->aead)
NLA_PUT(skb, XFRMA_ALG_AEAD, aead_len(x->aead), x->aead);
- if (x->aalg)
- NLA_PUT(skb, XFRMA_ALG_AUTH, xfrm_alg_len(x->aalg), x->aalg);
+ if (x->aalg) {
+ if (copy_to_user_auth(x->aalg, skb))
+ goto nla_put_failure;
+
+ NLA_PUT(skb, XFRMA_ALG_AUTH_TRUNC,
+ xfrm_alg_auth_len(x->aalg), x->aalg);
+ }
if (x->ealg)
NLA_PUT(skb, XFRMA_ALG_CRYPT, xfrm_alg_len(x->ealg), x->ealg);
if (x->calg)
@@ -2117,8 +2227,11 @@ static inline size_t xfrm_sa_len(struct xfrm_state *x)
size_t l = 0;
if (x->aead)
l += nla_total_size(aead_len(x->aead));
- if (x->aalg)
- l += nla_total_size(xfrm_alg_len(x->aalg));
+ if (x->aalg) {
+ l += nla_total_size(sizeof(struct xfrm_algo) +
+ (x->aalg->alg_key_len + 7) / 8);
+ l += nla_total_size(xfrm_alg_auth_len(x->aalg));
+ }
if (x->ealg)
l += nla_total_size(xfrm_alg_len(x->ealg));
if (x->calg)
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/3] xfrm: Use the user specified truncation length in ESP and AH
From: Martin Willi @ 2009-11-25 10:29 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
In-Reply-To: <cover.1259142145.git.martin@strongswan.org>
Instead of using the hardcoded truncation for authentication
algorithms, use the truncation length specified on xfrm_state.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
net/ipv4/ah4.c | 2 +-
net/ipv4/esp4.c | 2 +-
net/ipv6/ah6.c | 2 +-
net/ipv6/esp6.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 5c66270..b7be5ed 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -261,7 +261,7 @@ static int ah_init_state(struct xfrm_state *x)
}
ahp->icv_full_len = aalg_desc->uinfo.auth.icv_fullbits/8;
- ahp->icv_trunc_len = aalg_desc->uinfo.auth.icv_truncbits/8;
+ ahp->icv_trunc_len = x->aalg->alg_trunc_len/8;
BUG_ON(ahp->icv_trunc_len > MAX_AH_AUTH_LEN);
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 12f7287..1948895 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -530,7 +530,7 @@ static int esp_init_authenc(struct xfrm_state *x)
}
err = crypto_aead_setauthsize(
- aead, aalg_desc->uinfo.auth.icv_truncbits / 8);
+ aead, x->aalg->alg_trunc_len / 8);
if (err)
goto free_key;
}
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index c1589e2..0c2ae68 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -469,7 +469,7 @@ static int ah6_init_state(struct xfrm_state *x)
}
ahp->icv_full_len = aalg_desc->uinfo.auth.icv_fullbits/8;
- ahp->icv_trunc_len = aalg_desc->uinfo.auth.icv_truncbits/8;
+ ahp->icv_trunc_len = x->aalg->alg_trunc_len/8;
BUG_ON(ahp->icv_trunc_len > MAX_AH_AUTH_LEN);
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index af597c7..668a46b 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -473,7 +473,7 @@ static int esp_init_authenc(struct xfrm_state *x)
}
err = crypto_aead_setauthsize(
- aead, aalg_desc->uinfo.auth.icv_truncbits / 8);
+ aead, x->aalg->alg_trunc_len / 8);
if (err)
goto free_key;
}
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints
From: Andi Kleen @ 2009-11-25 10:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, David Miller, peter.p.waskiewicz.jr, peterz, arjan,
yong.zhang0, linux-kernel, arjan, netdev
In-Reply-To: <4B0D0742.2050301@gmail.com>
Works here
>
> dmesg | grep -i node
> [ 0.000000] SRAT: PXM 0 -> APIC 0 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 1 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 2 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 3 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 4 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 5 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 6 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 7 -> Node 0
You seem to only have 8 CPUs (one socket) Normally a dual socket nehalem
should have 16 with HyperThreading enabled.
For some reason the BIOS is not reporting the other CPU.
You could double check with acpidmp / iasl -d if that's
what the BIOS really reports, but normally it should work.
> [ 0.000000] SRAT: Node 0 PXM 0 0-e0000000
> [ 0.000000] SRAT: Node 0 PXM 0 100000000-220000000
> [ 0.000000] SRAT: Node 1 PXM 1 220000000-420000000
-Andi
^ permalink raw reply
* Re: [PATCH] irq: Add node_affinity CPU masks for smarter irqbalance hints
From: Eric Dumazet @ 2009-11-25 10:30 UTC (permalink / raw)
To: Andi Kleen
Cc: David Miller, peter.p.waskiewicz.jr, peterz, arjan, yong.zhang0,
linux-kernel, arjan, netdev
In-Reply-To: <4B0C4624.9080607@gmail.com>
Eric Dumazet a écrit :
> Andi Kleen a écrit :
>> They are typically allocated with dma_alloc_coherent(), which does
>> allocate a continuous area. In theory you could do interleaving
>> with IOMMus, but just putting it on the same node as the device
>> is probably better.
>
> There are two parts, biggest one allocated with vmalloc()
> (to hold struct ixgbe_rx_buffer array, 32 bytes or more per entry),
> only used by driver (not adapter)
>
> and one allocated with pci_alloc_consistent()
> (to hold ixgbe_adv_tx_desc array, 16 bytes per entry)
>
> vmalloc() one could be spreaded on many nodes.
> I am not speaking about the pci_alloc_consistent() one :)
>
BTW, I found my Nehalem dev machine behaves strangly, defeating all
my NUMA tweaks. (This is an HP DL380 G6)
It has two sockets, populated with two E5530 @2.4GH.
Each cpu has 2x4GB RAM modules.
It claims having two memory nodes, but all cpus are on Node 0
dmesg | grep -i node
[ 0.000000] SRAT: PXM 0 -> APIC 0 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 1 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 2 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 3 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 4 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 5 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 6 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 7 -> Node 0
[ 0.000000] SRAT: Node 0 PXM 0 0-e0000000
[ 0.000000] SRAT: Node 0 PXM 0 100000000-220000000
[ 0.000000] SRAT: Node 1 PXM 1 220000000-420000000
[ 0.000000] Bootmem setup node 0 0000000000000000-0000000220000000
[ 0.000000] NODE_DATA [0000000000001000 - 0000000000004fff]
[ 0.000000] Bootmem setup node 1 0000000220000000-000000041ffff000
[ 0.000000] NODE_DATA [0000000220000000 - 0000000220003fff]
[ 0.000000] [ffffea0000000000-ffffea00087fffff] PMD -> [ffff880028600000-ffff8800305fffff] on node 0
[ 0.000000] [ffffea0008800000-ffffea00107fffff] PMD -> [ffff880220200000-ffff8802281fffff] on node 1
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[5] active PFN ranges
[ 0.000000] On node 0 totalpages: 2094543
[ 0.000000] On node 1 totalpages: 2097151
[ 0.000000] NR_CPUS:16 nr_cpumask_bits:16 nr_cpu_ids:16 nr_node_ids:2
[ 0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=2
[ 0.004756] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.007213] CPU 0/0x0 -> Node 0
[ 0.398104] CPU 1/0x10 -> Node 0
[ 0.557854] CPU 2/0x4 -> Node 0
[ 0.717606] CPU 3/0x14 -> Node 0
[ 0.877357] CPU 4/0x2 -> Node 0
[ 1.037109] CPU 5/0x12 -> Node 0
[ 1.196860] CPU 6/0x6 -> Node 0
[ 1.356611] CPU 7/0x16 -> Node 0
[ 1.516365] CPU 8/0x1 -> Node 0
[ 1.676114] CPU 9/0x11 -> Node 0
[ 1.835865] CPU 10/0x5 -> Node 0
[ 1.995616] CPU 11/0x15 -> Node 0
[ 2.155367] CPU 12/0x3 -> Node 0
[ 2.315119] CPU 13/0x13 -> Node 0
[ 2.474870] CPU 14/0x7 -> Node 0
[ 2.634621] CPU 15/0x17 -> Node 0
# cat /proc/buddyinfo
Node 0, zone DMA 2 2 2 1 1 1 1 0 1 1 3
Node 0, zone DMA32 5 11 4 5 4 12 1 4 4 5 834
Node 0, zone Normal 4109 120 98 153 67 35 21 15 11 10 109
Node 1, zone Normal 7 17 10 12 7 14 5 7 6 5 2004
This is with net-next-2.6, I'll try linux-2.6
^ permalink raw reply
* [PATCH 1/3] xfrm: Define new XFRM netlink auth attribute with specified truncation bits
From: Martin Willi @ 2009-11-25 10:29 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
In-Reply-To: <cover.1259142145.git.martin@strongswan.org>
The new XFRMA_ALG_AUTH_TRUNC attribute taking a xfrm_algo_auth as
argument allows the installation of authentication algorithms with
a truncation length specified in userspace, i.e. SHA256 with 128 bit
instead of 96 bit truncation.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
include/linux/xfrm.h | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index 2d4ec15..d28e853 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -96,6 +96,13 @@ struct xfrm_algo {
char alg_key[0];
};
+struct xfrm_algo_auth {
+ char alg_name[64];
+ unsigned int alg_key_len; /* in bits */
+ unsigned int alg_trunc_len; /* in bits */
+ char alg_key[0];
+};
+
struct xfrm_algo_aead {
char alg_name[64];
unsigned int alg_key_len; /* in bits */
@@ -283,6 +290,7 @@ enum xfrm_attr_type_t {
XFRMA_MIGRATE,
XFRMA_ALG_AEAD, /* struct xfrm_algo_aead */
XFRMA_KMADDRESS, /* struct xfrm_user_kmaddress */
+ XFRMA_ALG_AUTH_TRUNC, /* struct xfrm_algo_auth */
__XFRMA_MAX
#define XFRMA_MAX (__XFRMA_MAX - 1)
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/3] xfrm: Custom truncation lengths for authentication algorithms
From: Martin Willi @ 2009-11-25 10:29 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
The following patchset adds support for defining truncation lengths
for authentication algorithms in userspace. The main purpose for this
is to support SHA256 in IPsec using the standardized 128 bit
instead of the currently used 96 bit truncation.
Martin Willi (3):
xfrm: Define new XFRM netlink auth attribute with specified
truncation bits
xfrm: Store aalg in xfrm_state with a user specified truncation
length
xfrm: Use the user specified truncation length in ESP and AH
include/linux/xfrm.h | 8 +++
include/net/xfrm.h | 12 ++++-
net/ipv4/ah4.c | 2 +-
net/ipv4/esp4.c | 2 +-
net/ipv6/ah6.c | 2 +-
net/ipv6/esp6.c | 2 +-
net/xfrm/xfrm_state.c | 2 +-
net/xfrm/xfrm_user.c | 129 ++++++++++++++++++++++++++++++++++++++++++++++---
8 files changed, 145 insertions(+), 14 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
From: Rusty Russell @ 2009-11-25 10:20 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shirley Ma, Eric Dumazet, Avi Kivity, netdev, kvm, linux-kernel,
Hollis Blanchard
In-Reply-To: <20091125091530.GA6357@redhat.com>
On Wed, 25 Nov 2009 07:45:30 pm Michael S. Tsirkin wrote:
> Hmm, is it really worth it to save a header copy if it's linear? We are
> going to access it anyway, and it fits into one cacheline nicely. On
> the other hand we have more code making life harder for compiler and
> processor.
Not sure: I think there would be many places where it would be useful.
We do a similar thing in the kernel to inspect non-linear packets, and
it's served us well.
Cheers,
Rusty.
^ permalink raw reply
* [ethtool PATCH] ethtool: Add Direct Attach to the available connector ports
From: Jeff Kirsher @ 2009-11-25 10:13 UTC (permalink / raw)
To: jeff, davem, shemminger
Cc: netdev, gospo, Peter P Waskiewicz Jr, Jeff Kirsher
From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
This adds Direct Attach SFP+ types to the connector ports
for the GSET mode.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
ethtool-copy.h | 3 +++
ethtool.c | 6 ++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 3ca4e2c..7ea5a1b 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -402,6 +402,9 @@ struct ethtool_rxnfc {
#define PORT_MII 0x02
#define PORT_FIBRE 0x03
#define PORT_BNC 0x04
+#define PORT_DA 0x05
+#define PORT_NONE 0xef
+#define PORT_OTHER 0xff
/* Which transceiver to use. */
#define XCVR_INTERNAL 0x00
diff --git a/ethtool.c b/ethtool.c
index 0110682..5b77614 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -942,6 +942,12 @@ static int dump_ecmd(struct ethtool_cmd *ep)
case PORT_FIBRE:
fprintf(stdout, "FIBRE\n");
break;
+ case PORT_DA:
+ fprintf(stdout, "Direct Attach Copper\n");
+ break;
+ case PORT_NONE:
+ fprintf(stdout, "None\n");
+ break;
default:
fprintf(stdout, "Unknown! (%i)\n", ep->port);
break;
^ permalink raw reply related
* [net-next-2.6 PATCH 2/2] ixgbe: Display currently attached PHY through ethtool
From: Jeff Kirsher @ 2009-11-25 10:11 UTC (permalink / raw)
To: davem, jeff, shemminger
Cc: netdev, gospo, Peter P Waskiewicz Jr, Jeff Kirsher
In-Reply-To: <20091125101128.24430.89112.stgit@localhost.localdomain>
From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
This patch extends the ethtool interface to display what PHY
is currently connected to a NIC. The results can be viewed in
ethtool ethX output.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_ethtool.c | 50 +++++++++++++++++++++++++++++++++++++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index 84ab4db..ec59c53 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -205,6 +205,56 @@ static int ixgbe_get_settings(struct net_device *netdev,
ecmd->autoneg = AUTONEG_DISABLE;
}
+ /* Get PHY type */
+ switch (adapter->hw.phy.type) {
+ case ixgbe_phy_tn:
+ case ixgbe_phy_cu_unknown:
+ /* Copper 10G-BASET */
+ ecmd->port = PORT_TP;
+ break;
+ case ixgbe_phy_qt:
+ ecmd->port = PORT_FIBRE;
+ break;
+ case ixgbe_phy_nl:
+ case ixgbe_phy_tw_tyco:
+ case ixgbe_phy_tw_unknown:
+ case ixgbe_phy_sfp_ftl:
+ case ixgbe_phy_sfp_avago:
+ case ixgbe_phy_sfp_intel:
+ case ixgbe_phy_sfp_unknown:
+ switch (adapter->hw.phy.sfp_type) {
+ /* SFP+ devices, further checking needed */
+ case ixgbe_sfp_type_da_cu:
+ case ixgbe_sfp_type_da_cu_core0:
+ case ixgbe_sfp_type_da_cu_core1:
+ ecmd->port = PORT_DA;
+ break;
+ case ixgbe_sfp_type_sr:
+ case ixgbe_sfp_type_lr:
+ case ixgbe_sfp_type_srlr_core0:
+ case ixgbe_sfp_type_srlr_core1:
+ ecmd->port = PORT_FIBRE;
+ break;
+ case ixgbe_sfp_type_not_present:
+ ecmd->port = PORT_NONE;
+ break;
+ case ixgbe_sfp_type_unknown:
+ default:
+ ecmd->port = PORT_OTHER;
+ break;
+ }
+ break;
+ case ixgbe_phy_xaui:
+ ecmd->port = PORT_NONE;
+ break;
+ case ixgbe_phy_unknown:
+ case ixgbe_phy_generic:
+ case ixgbe_phy_sfp_unsupported:
+ default:
+ ecmd->port = PORT_OTHER;
+ break;
+ }
+
hw->mac.ops.check_link(hw, &link_speed, &link_up, false);
if (link_up) {
ecmd->speed = (link_speed == IXGBE_LINK_SPEED_10GB_FULL) ?
^ permalink raw reply related
* [net-next-2.6 PATCH 1/2] ethtool: Add Direct Attach support to connector port reporting
From: Jeff Kirsher @ 2009-11-25 10:11 UTC (permalink / raw)
To: davem, jeff, shemminger
Cc: netdev, gospo, Peter P Waskiewicz Jr, Jeff Kirsher
From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
This patch allows a base driver to specify Direct Attach as the
type of port through the ethtool interface.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
include/linux/ethtool.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index edd03b7..bcaa0e0 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -631,6 +631,8 @@ struct ethtool_ops {
#define PORT_MII 0x02
#define PORT_FIBRE 0x03
#define PORT_BNC 0x04
+#define PORT_DA 0x05
+#define PORT_NONE 0xef
#define PORT_OTHER 0xff
/* Which transceiver to use. */
^ permalink raw reply related
* Re: [PATCH net-next-2.6] ixgbe: Fix TX stats accounting
From: Jeff Kirsher @ 2009-11-25 9:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: Peter P Waskiewicz Jr, robert@herjulf.net, Jesper Dangaard Brouer,
Linux Netdev List, David S. Miller
In-Reply-To: <4B0CF974.2070702@gmail.com>
On Wed, Nov 25, 2009 at 01:31, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Jeff Kirsher a écrit :
>>
>> Thanks Eric. I have added the patch to my tree for testing and review.
>>
>
> Thanks Jeff, a similar problem on RX stats should also be addressed.
>
> Is your tree public ?
>
Unfortunately we do not have a public tree at this time. I do welcome
any patches you want to submit.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH net-next-2.6] ixgbe: Fix TX stats accounting
From: Eric Dumazet @ 2009-11-25 9:31 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Peter P Waskiewicz Jr, robert@herjulf.net, Jesper Dangaard Brouer,
Linux Netdev List, David S. Miller
In-Reply-To: <9929d2390911242338m6c4b322dod7a8af4c3c386d56@mail.gmail.com>
Jeff Kirsher a écrit :
>
> Thanks Eric. I have added the patch to my tree for testing and review.
>
Thanks Jeff, a similar problem on RX stats should also be addressed.
Is your tree public ?
^ permalink raw reply
* [PATCH] don't wrap mlx4_remove_one in __devexit_p
From: Uwe Kleine-König @ 2009-11-25 9:23 UTC (permalink / raw)
To: linux-kernel
Cc: Roland Dreier, Yevgeny Petrilin, Yang Hongyang, Jack Morgenstein,
Eli Cohen, Andrew Morton, netdev, Franco Fichtner
In-Reply-To: <4B0CF685.6060208@lastsummer.de>
The function mlx4_remove_one is defined in .text, so there is no need to
wrap it with __devexit_p.
While at it add a trailing comma to the section initializer.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Roland Dreier <rolandd@cisco.com>
Cc: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Cc: Yang Hongyang <yanghy@cn.fujitsu.com>
Cc: Jack Morgenstein <jackm@dev.mellanox.co.il>
Cc: Eli Cohen <eli@mellanox.co.il>
Cc: linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: netdev@vger.kernel.org
Cc: Franco Fichtner <franco@lastsummer.de>
---
drivers/net/mlx4/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/mlx4/main.c b/drivers/net/mlx4/main.c
index 291a505..acc2878 100644
--- a/drivers/net/mlx4/main.c
+++ b/drivers/net/mlx4/main.c
@@ -1293,7 +1293,7 @@ static struct pci_driver mlx4_driver = {
.name = DRV_NAME,
.id_table = mlx4_pci_table,
.probe = mlx4_init_one,
- .remove = __devexit_p(mlx4_remove_one)
+ .remove = mlx4_remove_one,
};
static int __init mlx4_verify_params(void)
^ permalink raw reply related
* Re: Diagnostic Monitoring Interface Monitoring (DOM) PATCH 0/5 for net-next-2.6
From: Jeff Kirsher @ 2009-11-25 9:19 UTC (permalink / raw)
To: Robert Olsson; +Cc: David Miller, netdev
In-Reply-To: <9929d2390911250018o777405ddk257605e7d0b16d17@mail.gmail.com>
On Wed, Nov 25, 2009 at 00:18, Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> On Mon, Nov 23, 2009 at 14:45, Robert Olsson <robert@herjulf.net> wrote:
>>
>> Here are basic support to bring Diagnostic Monitoring Interface Monitoring (DOM)
>> to Linux this is more or less mandatory when building optical networks.
>>
>> Optical modules as SFP, SFP+, XFP, GBIC etc holds transceiver and link diagnostic
>> data needed to monitor and troubleshoot optical links, Talks to networks cards
>> via the I2C-bus (DOM lives in memory page 0xA2).
>>
>> In essential:
>>
>> Usage example: ethtool -D eth5
>>
>> Ext-Calbr: Avr RX-Power: Alarm & Warn: RX_LOS: Wavelength: 1310 nm
>> Alarms, warnings in beginning of line, Ie. AH = Alarm High, WL == Warn Low etc
>> Temp: 35.9 C Thresh: Lo: -12.0/-8.0 Hi: 103.0/110.0 C
>> Vcc: 3.33 V Thresh: Lo: 3.0/3.0 Hi: 3.7/4.0 V
>> Tx-Bias: 13.4 mA Thresh: Lo: 2.0/4.0 Hi: 70.0/84.0 mA
>> ALWL TX-pwr: -5.9 dBm ( 0.26 mW) Thresh: Lo: -4.0/-2.0 Hi: 7.0/8.2 dBm
>> AHWH RX-pwr: -5.0 dBm ( 0.31 mW) Thresh: Lo: -35.2/-28.0 Hi: -8.2/-6.0 dBm
>>
>> Read more in Documentation/networking/dom.txt
>>
>> It's tested with the igb driver, there is also a patch for the ixgbe driver but I
>> haven't any SFP+ with DOM support yet.
>>
>>
>> There are room for improvements an clean-ups.
>>
>> Cheers
>> --ro
>>
>
> Robert, to help get more eyes on this I have added it to my tree for
> internal testing and review.
>
FYI- This patch series is riddled with trailing whitespace, when I
imported that patches into my tree, I cleaned up all the whitespace
errors. After some internal testing and review, I can re-post the
entire series which has been cleaned up.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH 10/38] don't wrap mlx4_remove_one in __devexit_p
From: Franco Fichtner @ 2009-11-25 9:19 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-kernel, akpm, Roland Dreier, Yevgeny Petrilin,
Yang Hongyang, Jack Morgenstein, Eli Cohen, netdev
In-Reply-To: <1259096853-18909-10-git-send-email-u.kleine-koenig@pengutronix.de>
Uwe Kleine-König wrote:
> diff --git a/drivers/net/mlx4/main.c b/drivers/net/mlx4/main.c
> index 291a505..a581860 100644
> --- a/drivers/net/mlx4/main.c
> +++ b/drivers/net/mlx4/main.c
> @@ -1293,7 +1293,7 @@ static struct pci_driver mlx4_driver = {
> .name = DRV_NAME,
> .id_table = mlx4_pci_table,
> .probe = mlx4_init_one,
> - .remove = __devexit_p(mlx4_remove_one)
> + .remove = mlx4_remove_one
>
You may want to add the trailing comma while you're at it...
> };
>
> static int __init mlx4_verify_params(void)
>
f
^ permalink raw reply
* Re: [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
From: Michael S. Tsirkin @ 2009-11-25 9:15 UTC (permalink / raw)
To: Rusty Russell
Cc: Shirley Ma, Eric Dumazet, Avi Kivity, netdev, kvm, linux-kernel,
Hollis Blanchard
In-Reply-To: <200911251042.06368.rusty@rustcorp.com.au>
On Wed, Nov 25, 2009 at 10:42:06AM +1030, Rusty Russell wrote:
> On Tue, 24 Nov 2009 10:07:54 pm Michael S. Tsirkin wrote:
> > On Tue, Nov 24, 2009 at 08:54:23AM +1030, Rusty Russell wrote:
> > > On Tue, 24 Nov 2009 02:37:01 am Shirley Ma wrote:
> > > > > > + skb = (struct sk_buff *)buf;
> > > > > This cast is unnecessary, but a comment would be nice:
> > > >
> > > > Without this cast there is a compile warning.
> > >
> > > Hi Shirley,
> > >
> > > Looks like buf is a void *, so no cast should be necessary. But I could
> > > be reading the patch wrong.
> > >
> > > > > However, I question whether making it 16 byte is the right thing: the
> > > > > ethernet header is 14 bytes long, so don't we want 8 bytes of padding?
> > > >
> > > > Because in QEMU it requires 10 bytes header in a separately, so one page
> > > > is used to share between virtio_net_hdr header which is 10 bytes head
> > > > and rest of data. So I put 6 bytes offset here between two buffers. I
> > > > didn't look at the reason why a seperate buf is used for virtio_net_hdr
> > > > in QEMU.
> > >
> > > It's a qemu bug. It insists the header be an element in the scatterlist by
> > > itself. Unfortunately we have to accommodate it.
> >
> > We do? Let's just fix this?
> > All we have to do is replace memcpy with proper iovec walk, correct?
> > Something like the followng (untested) patch? It's probably not too
> > late to put this in the next qemu release...
>
> You might want to implement a more generic helper which does:
>
> /* Return pointer into iovec if we can, otherwise copy into buf */
> void *pull_iovec(struct iovec *iov, int iovcnt, void *buf, size_t len)
> {
> unsigned int i;
> void *p;
>
> if (likely(iov_cnt && iov[0].iov_len >= len)) {
> /* Nice contiguous chunk. */
> void *p = iov[0].iov_base;
> iov[i].iov_base += len;
> iov[i].iov_len -= len;
> return p;
> }
>
> p = buf;
> for (i = 0; i < iov_cnt; i++) {
> size_t this_len = min(len, iov[i].iov_len);
> memcpy(p, iov[i].iov_base, this_len);
> len -= this_len;
> iov[i].iov_base += len;
> iov[i].iov_len -= len;
> if (len == 0)
> return buf;
> }
> /* BTW, we screwed your iovec. */
> return NULL;
> }
>
> Then use it in all the virtio drivers...
Hmm, is it really worth it to save a header copy if it's linear? We are
going to access it anyway, and it fits into one cacheline nicely. On
the other hand we have more code making life harder for compiler and
processor.
> Thanks!
> Rusty.
^ 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