Netdev List
 help / color / mirror / Atom feed
* Re: hackbench regression due to commit 9dfc6e68bfe6e
From: Eric Dumazet @ 2010-04-08  5:39 UTC (permalink / raw)
  To: Zhang, Yanmin
  Cc: Christoph Lameter, Pekka Enberg, netdev, Tejun Heo, alex.shi,
	linux-kernel@vger.kernel.org, Ma, Ling, Chen, Tim C,
	Andrew Morton
In-Reply-To: <1270702774.8141.49.camel@edumazet-laptop>


I suspect NUMA is completely out of order on current kernel, or my
Nehalem machine NUMA support is a joke

# numactl --hardware
available: 2 nodes (0-1)
node 0 size: 3071 MB
node 0 free: 2637 MB
node 1 size: 3062 MB
node 1 free: 2909 MB


# cat try.sh
hackbench 50 process 5000
numactl --cpubind=0 --membind=0 hackbench 25 process 5000 >RES0 &
numactl --cpubind=1 --membind=1 hackbench 25 process 5000 >RES1 &
wait
echo node0 results
cat RES0
echo node1 results
cat RES1

numactl --cpubind=0 --membind=1 hackbench 25 process 5000 >RES0_1 &
numactl --cpubind=1 --membind=0 hackbench 25 process 5000 >RES1_0 &
wait
echo node0 on mem1 results
cat RES0_1
echo node1 on mem0 results
cat RES1_0

# ./try.sh
Running with 50*40 (== 2000) tasks.
Time: 16.865
node0 results
Running with 25*40 (== 1000) tasks.
Time: 16.767
node1 results
Running with 25*40 (== 1000) tasks.
Time: 16.564
node0 on mem1 results
Running with 25*40 (== 1000) tasks.
Time: 16.814
node1 on mem0 results
Running with 25*40 (== 1000) tasks.
Time: 16.896



^ permalink raw reply

* linux-next: build failure after merge of the final tree
From: Stephen Rothwell @ 2010-04-08  5:35 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: linux-next, linux-kernel, John Linn, John Tyner

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

Hi all,

After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/net/ll_temac_main.c: In function 'll_temac_recv':
drivers/net/ll_temac_main.c:695: error: implicit declaration of function 'virt_to_bus'

Caused by commit 459569145516f7967b916c57445feb02c600668c ("Add
non-Virtex5 support for LL TEMAC driver") from the net tree.

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: [PATCH] myri10ge: fix rx_pause in myri10ge_set_pauseparam
From: David Miller @ 2010-04-08  5:23 UTC (permalink / raw)
  To: brice; +Cc: netdev
In-Reply-To: <4BBD67D8.8000104@myri.com>

From: Brice Goglin <brice@myri.com>
Date: Thu, 08 Apr 2010 07:21:28 +0200

> Fix rx_pause management in myri10ge_set_pauseparam().
> 
> Signed-off-by: Brice Goglin <brice@myri.com>

Applied, thanks.

^ permalink raw reply

* [PATCH] myri10ge: fix rx_pause in myri10ge_set_pauseparam
From: Brice Goglin @ 2010-04-08  5:21 UTC (permalink / raw)
  To: David S. Miller; +Cc: Linux Network Development list
In-Reply-To: <4BB8ADE4.5090304@myri.com>

Fix rx_pause management in myri10ge_set_pauseparam().

Signed-off-by: Brice Goglin <brice@myri.com>

diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index e84dd3e..3cb7607 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -1689,7 +1689,7 @@ myri10ge_set_pauseparam(struct net_device *netdev,
 	if (pause->tx_pause != mgp->pause)
 		return myri10ge_change_pause(mgp, pause->tx_pause);
 	if (pause->rx_pause != mgp->pause)
-		return myri10ge_change_pause(mgp, pause->tx_pause);
+		return myri10ge_change_pause(mgp, pause->rx_pause);
 	if (pause->autoneg != 0)
 		return -EINVAL;
 	return 0;



^ permalink raw reply related

* Re: [PATCH] sky2: rx hash offload
From: David Miller @ 2010-04-08  5:04 UTC (permalink / raw)
  To: eric.dumazet; +Cc: shemminger, netdev, therbert
In-Reply-To: <1270557210.2081.8.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 06 Apr 2010 14:33:30 +0200

> Le lundi 05 avril 2010 à 08:48 -0700, Stephen Hemminger a écrit :
>> Marvell Yukon 2 hardware supports hardware receive hash calculation.
>> Now that Receive Packet Steering is available, add support
>> to enable it.
>> 
>> Note: still experimental, tested on only a few variants.
>> No performance testing has been done.
>> 
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>> 
>> ---
>>  drivers/net/sky2.c |   75 +++++++++++++++++++++++++++++++++++++++++++++++++++--
>>  drivers/net/sky2.h |   23 ++++++++++++++++
>>  2 files changed, 96 insertions(+), 2 deletions(-)
> 
> I am wondering if introducing hardware computed rxhash wouldnt force us
> to clear rxhash in several paths (tunneling...), so that we perform a
> software recompute after decapsulation, to enable RFS
> 
> Not mandatory but recommended I would say...

nf_reset() and clearing things like this new rxhash thing
should be encapsulated into a helper function that we can
stick into the tunnel drivers and such.

^ permalink raw reply

* Re: tulip_stop_rxtx() failed (CSR5 0xf0260000 CSR6 0xb3862002) on DEC Alpha Personal Workstation 433au
From: David Miller @ 2010-04-08  5:01 UTC (permalink / raw)
  To: glaubitz; +Cc: joe, grundler, kyle, netdev, linux-kernel
In-Reply-To: <20100407134228.GC31252@physik.fu-berlin.de>

From: Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Wed, 7 Apr 2010 15:42:28 +0200

> Hi,
> 
> On Mon, Apr 05, 2010 at 10:36:22AM -0700, Joe Perches wrote:
>> On Mon, 2010-04-05 at 19:13 +0200, Adrian Glaubitz wrote:
>> > Hi guys,
>> > 
>> > I installed Debian unstable on an old digital workstation "DEC Digital
>> > Personal Workstation 433au" (Miata) which has an on-board tulip
>> > network controller. I'm not really using that network controller but
>> > an off-board intel e1000 controller. However, I found that the tulip
>> > driver produces a lot of noise in the message log, the following
>> > message is repated periodically and spams the whole message log:
>> > 
>> > 0000:00:03.0: tulip_stop_rxtx() failed (CSR5 0xf0260000 CSR6 0xb3862002)
>> > 
>> > Do you think this is related to the fact that no cable is connected to
>> > the network controller?
>> 
>> Probably something is trying periodically to open the device.
>> Maybe this helps reduce the message log noise:
>> 
>> Signed-off-by: Joe Perches <joe@perches.com>
> 
> Acked-by: Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> 
> Patch works perfectly. Now the message log looks pretty normal.

This doesn't fix the problem, it just makes the message get
emitted in a rate limited manner.

I'm not going to apply this, we need to figure out what's causing
this problem instead of merely papering over it.

Thanks.

^ permalink raw reply

* Re: [PATCH v3 0/4] xfrm: add x86 CONFIG_COMPAT support
From: David Miller @ 2010-04-08  5:00 UTC (permalink / raw)
  To: fw; +Cc: netdev, johannes
In-Reply-To: <20100407133528.GD22518@Chamillionaire.breakpoint.cc>

From: Florian Westphal <fw@strlen.de>
Date: Wed, 7 Apr 2010 15:35:28 +0200

> But whats really bothering me is the number of sys_compat_* functions
> needed to make all possibilities work;. e.g. to make (unmodified)
> strongwan work, sys_compat_write and sys_compat_sendto are needed.

Thank the BSD socket API designer(s) for adding N different ways to
essentially say the same thing instead of just having sendmsg/recvmsg
and saying "if you don't want to specify X, just pass in NULL" or
whatever. :-)

Because that's all that sendto() is, it's a sendmsg() without
an arg or two.  But in the end the kernel internally has to
come up with pretend arguments for all of this stuff anyways
since the protocols end up having to accomodate all of
the sendmsg() cases anyways.

And it's not all that bad, we just need the numerous compat entry
points to set the compat flag bit, the rest of the implementation is
going to be %100 shared code.

And once it's there, we can use it for other similar cases, not
just xfrm netlink.

^ permalink raw reply

* Re: hackbench regression due to commit 9dfc6e68bfe6e
From: Eric Dumazet @ 2010-04-08  4:59 UTC (permalink / raw)
  To: Zhang, Yanmin
  Cc: Christoph Lameter, Pekka Enberg, netdev, Tejun Heo, alex.shi,
	linux-kernel@vger.kernel.org, Ma, Ling, Chen, Tim C,
	Andrew Morton
In-Reply-To: <1270688747.2078.383.camel@ymzhang.sh.intel.com>

Le jeudi 08 avril 2010 à 09:05 +0800, Zhang, Yanmin a écrit :

> > Do we have a user program to check actual L1 cache size of a machine ?
> If there is no, it's easy to write it as kernel exports the cache stat by
> /sys/devices/system/cpu/cpuXXX/cache/indexXXX/

Yes, this is what advertizes my L1 cache having 64bytes lines, but I
would like to check that in practice, this is not 128bytes...

./index0/type:Data
./index0/level:1
./index0/coherency_line_size:64
./index0/physical_line_partition:1
./index0/ways_of_associativity:8
./index0/number_of_sets:64
./index0/size:32K
./index0/shared_cpu_map:00000101
./index0/shared_cpu_list:0,8
./index1/type:Instruction
./index1/level:1
./index1/coherency_line_size:64
./index1/physical_line_partition:1
./index1/ways_of_associativity:4
./index1/number_of_sets:128
./index1/size:32K
./index1/shared_cpu_map:00000101
./index1/shared_cpu_list:0,8



^ permalink raw reply

* Re: [PATCH 1/1] - fix ethtool coding style errors and warnings
From: David Miller @ 2010-04-08  4:55 UTC (permalink / raw)
  To: chavey; +Cc: netdev, therbert
In-Reply-To: <pvmaateq2uv.fsf@chavey.mtv.corp.google.com>

From: chavey@google.com
Date: Wed, 07 Apr 2010 16:06:48 -0700

>>From dcdd5d730a5a0d72c11e5010c65ed3b827fc1b85 Mon Sep 17 00:00:00 2001
> From: chavey <chavey@google.com>
> Date: Wed, 7 Apr 2010 15:53:31 -0700
> 
> Fix coding style errors and warnings output while running checkpatch.pl
> on the files net/core/ethtool.c and include/linux/ethtool.h

Seems like pointless masterbation to me, but whatever,
applied.

> Signed-off-by: chavey <chavey@google.com>

Can I trouble you to put your real full name in at least your
signoffs instead of just a copy of your email address user
name?

Thanks.

^ permalink raw reply

* Re: [PATCH] macb: allow reception of large (>1518 bytes) frames
From: David Miller @ 2010-04-08  4:53 UTC (permalink / raw)
  To: peter.korsgaard; +Cc: haavard.skinnemoen, netdev, linux-kernel
In-Reply-To: <1270652389-5364-1-git-send-email-peter.korsgaard@barco.com>

From: Peter Korsgaard <peter.korsgaard@barco.com>
Date: Wed,  7 Apr 2010 16:59:49 +0200

> Enable BIG bit in the network configuration register, so the MAC doesn't
> reject big frames (E.G. when vlans are used).
> 
> Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>

Applied to net-next-2.6, thanks.

^ permalink raw reply

* Re: [PATCH] corrected documentation for hardware time stamping
From: David Miller @ 2010-04-08  4:53 UTC (permalink / raw)
  To: loschmidt, Patrick.Loschmidt; +Cc: netdev, patrick.ohly
In-Reply-To: <4BBC6944.2090102@OEAW.ac.at>

From: Patrick Loschmidt <Patrick.Loschmidt@OEAW.ac.at>
Date: Wed, 07 Apr 2010 13:15:16 +0200

> From: Patrick Loschmidt <Patrick.Loschmidt@oeaw.ac.at>
> 
> The current documentation for hardware time stamping does not correctly specify the available kernel
> functions since the implementation was changed later on.
> 
> Signed-off-by: Patrick Loschmidt <Patrick.Loschmidt@oeaw.ac.at>

Applied thanks.

> --- Documentation/networking/timestamping.txt.orig	2010-04-07 12:52:47.000000000 +0200
> +++ Documentation/networking/timestamping.txt	2010-04-07 11:43:57.000000000 +0200

Please "-p1" base your patches in the future.

>  	/* PTP v1, UDP, any kind of event packet */
>  	HWTSTAMP_FILTER_PTP_V1_L4_EVENT,
> -
> -        ...
> +	

That line has extraneous trailing whitespace which I needed
to fix up when applying your patch.

Please attend to these details properly in future patch
submissions, as it will save me a lot of time.

Thanks.

^ permalink raw reply

* Re: [patch] stmmac: use resource_size()
From: David Miller @ 2010-04-08  4:50 UTC (permalink / raw)
  To: error27; +Cc: peppe.cavallaro, joe, tj, cl, netdev, kernel-janitors
In-Reply-To: <20100407093546.GF5157@bicker>

From: Dan Carpenter <error27@gmail.com>
Date: Wed, 7 Apr 2010 12:35:46 +0300

> Resource size should be calculated as end - start + 1 because we start
> counting at zero.  I changed the code to resource_size() to do the 
> calculation.
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>

Applied, thanks Dan.

^ permalink raw reply

* Re: [PATCH] packet: support for TX time stamps on RAW sockets
From: David Miller @ 2010-04-08  4:47 UTC (permalink / raw)
  To: richardcochran; +Cc: netdev, patrick.ohly
In-Reply-To: <20100406143030.GA26954@riccoc20.at.omicron.at>

From: Richard Cochran <richardcochran@gmail.com>
Date: Tue, 6 Apr 2010 16:30:30 +0200

> Enable the SO_TIMESTAMPING socket infrastructure for raw packet sockets.
> For lack of a better idea, we have elected to use PACKET_RECV_OUTPUT for
> the control message cmsg_type. This macro currently is not used anywhere
> within the kernel.
> 
> Similar support for UDP and CAN sockets was added in commit
> 51f31cabe3ce5345b51e4a4f82138b38c4d5dc91
> 
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>

Why not add some new value, with a well formed name, just to make it
explicit what it's used for?


> +	put_cmsg(msg,SOL_PACKET,PACKET_RECV_OUTPUT,sizeof(serr->ee),&serr->ee);

Spaces between arguments, and you'll thus need to break this up into
multiple lines to keep it within 80 columns.

^ permalink raw reply

* Re: re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
From: David Miller @ 2010-04-08  4:45 UTC (permalink / raw)
  To: epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8
  Cc: dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f,
	rfiler-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1270517948.14692.9.camel@Linuxdev4-laptop>

From: Elina Pasheva <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>
Date: Mon, 5 Apr 2010 18:39:08 -0700

> Subject: re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
> From: Elina Pasheva <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>

I want you to tell me exactly how you generated this patch.

It doesn't apply, and I suspect that you tried to fix the excess empty
lines at the end of certain files by editing the patch by hand.

If so, did you test the result?

The patch is corrupted and more importantly git won't accept it.

davem@sunset:~/src/GIT/net-2.6$ git am --signoff re-submit3-ANNOUNCEMENT-NET-usb-sierra_net.c-driver.patch 
Applying: re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
/home/davem/src/GIT/net-2.6/.git/rebase-apply/patch:36: new blank line at EOF.
+
error: drivers/net/usb/sierra_net.c: does not exist in index
Patch failed at 0001 re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2] rfs: Receive Flow Steering
From: David Miller @ 2010-04-08  4:40 UTC (permalink / raw)
  To: therbert; +Cc: davem, netdev, eric.dumazet
In-Reply-To: <alpine.DEB.1.00.1004052248390.29212@pokey.mtv.corp.google.com>

From: Tom Herbert <therbert@google.com>
Date: Mon, 5 Apr 2010 22:56:50 -0700 (PDT)

> @@ -2342,6 +2387,10 @@ static int enqueue_to_backlog(struct sk_buff *skb, int cpu)
>  		if (queue->input_pkt_queue.qlen) {
>  enqueue:
>  			__skb_queue_tail(&queue->input_pkt_queue, skb);
> +#ifdef CONFIG_RPS
> +			*qtail = queue->input_queue_head +
> +			    queue->input_pkt_queue.qlen;
> +#endif
>  			rps_unlock(queue);
>  			local_irq_restore(flags);
>  			return NET_RX_SUCCESS;
 ...
> @@ -2801,6 +2864,9 @@ static void flush_backlog(void *arg)
>  		if (skb->dev == dev) {
>  			__skb_unlink(skb, &queue->input_pkt_queue);
>  			kfree_skb(skb);
> +#ifdef CONFIG_RPS
> +			queue->input_queue_head++;
> +#endif
>  		}
>  	rps_unlock(queue);
>  }

Please abstract these behind inline functions that live in
some header file, so we don't need to continually pepper
dev.c with countless ifdefs.

If you fix this and the kernel command line --> sysctl thing
Eric pointed out, I think I can apply this to net-next-2.6

Thanks.


^ permalink raw reply

* Re: patch to improve x.25 throughput negotiation
From: David Miller @ 2010-04-08  4:33 UTC (permalink / raw)
  To: andrew.hendry; +Cc: john, netdev
In-Reply-To: <v2jd45a3acc1004060509u88f32fa1va0c374154806535b@mail.gmail.com>

From: andrew hendry <andrew.hendry@gmail.com>
Date: Tue, 6 Apr 2010 22:09:10 +1000

> I have reproduced a few ways.
> 1. X25_MASK_THROUGHPUT on the x25_subscript_struct, then call
> SIOCX25SSUBSCRIP, then call SIOCX25FACILITIES without setting the
> throughput field. Call connect.
> 2. No subscrip setting, call SIOCX25FACILITIES without setting the
> throughput field. Call connect.
> 3. No subcrip, no facilities ioctl, call connect.
> 
> The patch removes the bad facility and makes the router accept the
> call for the above cases.
> I don't currently have a setup to test both direction throughput negotiation.
> 
> Tested-by: Andrew Hendry <andrew.hendry@gmail.com>

Patch applied, thanks everyone.

^ permalink raw reply

* Re: Patch to fix kernel bug 15678 - x25 code accesses fields beyond the end of packet.
From: David Miller @ 2010-04-08  4:29 UTC (permalink / raw)
  To: john; +Cc: netdev
In-Reply-To: <4BB8C0F1.2090100@Calva.COM>

From: John Hughes <john@Calva.COM>
Date: Sun, 04 Apr 2010 18:40:17 +0200

> From: John Hughes <john@calva.com>
> Subject: Patch to fix bug 15678 - x25 accesses fields beyond end of packet.
> 
> Here is a patch to stop X.25 examining fields beyond the end of the packet.
> 
> For example, when a simple CALL ACCEPTED was received:
> 
> 	10 10 0f
> 
> x25_parse_facilities was attempting to decode the FACILITIES field, but this
> packet contains no facilities field.
> 
> Signed-off-by: John Hughes <john@calva.com>

Applied, thanks John.

^ permalink raw reply

* Re: [PATCH] myri10ge: fix rx_pause in myri10ge_set_pauseparam
From: David Miller @ 2010-04-08  4:26 UTC (permalink / raw)
  To: brice; +Cc: netdev, gallatin
In-Reply-To: <4BB8ADE4.5090304@myri.com>

From: Brice Goglin <brice@myri.com>
Date: Sun, 04 Apr 2010 17:19:00 +0200

> Fix rx_pause in myri10ge_set_pauseparam().
> 
> Signed-off-by: Brice Goglin <brice@myri.com>

Your patch is tab/whitespace damaged by your email client.

Fix this up and resubmit, thanks.

^ permalink raw reply

* Re: bridge: Fix IGMP3 report parsing
From: David Miller @ 2010-04-08  4:21 UTC (permalink / raw)
  To: herbert; +Cc: netdev, banyeer
In-Reply-To: <20100408040709.GA19944@gondor.apana.org.au>

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 8 Apr 2010 12:07:09 +0800

> On Wed, Apr 07, 2010 at 08:52:48PM -0700, David Miller wrote:
>> 
>> If pskb_may_pull() actually does anything non-trivial,
>> skb->data will change and you'll be referring to freed
>> up memory.
>> 
>> That's probably why you had the grec assignment where
>> you originally had it in the first place :-)
> 
> Heh, you're clearly more awake than I was :)

:-)

> bridge: Fix IGMP3 report parsing
> 
> The IGMP3 report parsing is looking at the wrong address for
> group records.  This patch fixes it.
> 
> Reported-by: Banyeer <banyeer@yahoo.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied, thanks Herbert.

^ permalink raw reply

* Re: bridge: Fix IGMP3 report parsing
From: Herbert Xu @ 2010-04-08  4:07 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, banyeer
In-Reply-To: <20100407.205248.113724360.davem@davemloft.net>

On Wed, Apr 07, 2010 at 08:52:48PM -0700, David Miller wrote:
> 
> If pskb_may_pull() actually does anything non-trivial,
> skb->data will change and you'll be referring to freed
> up memory.
> 
> That's probably why you had the grec assignment where
> you originally had it in the first place :-)

Heh, you're clearly more awake than I was :)

bridge: Fix IGMP3 report parsing

The IGMP3 report parsing is looking at the wrong address for
group records.  This patch fixes it.

Reported-by: Banyeer <banyeer@yahoo.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 6980625..f29ada8 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -723,7 +723,7 @@ static int br_multicast_igmp3_report(struct net_bridge *br,
 		if (!pskb_may_pull(skb, len))
 			return -EINVAL;
 
-		grec = (void *)(skb->data + len);
+		grec = (void *)(skb->data + len - sizeof(*grec));
 		group = grec->grec_mca;
 		type = grec->grec_type;
 
Thanks,
-- 
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 related

* Re: [PATCH] bnx2x: use the dma state API instead of the pci equivalents
From: David Miller @ 2010-04-08  4:06 UTC (permalink / raw)
  To: eilong; +Cc: fujita.tomonori, netdev, vladz
In-Reply-To: <1270561278.1848.5.camel@lb-tlvb-eilong.il.broadcom.com>

From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Tue, 6 Apr 2010 16:41:18 +0300

> On Tue, 2010-04-06 at 00:39 -0700, Vladislav Zolotarov wrote:
>> Thanks, Fujita.
>> 
>> The patch looks fine. I'll run some regression tests on the patched driver to check that things still work and if it's ok we will ack it shortly.
>> 
>> vlad
>> 
>> 
> 
>> > =
>> > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
>> > Subject: [PATCH] bnx2x: use the DMA API instead of the pci equivalents
>> >
>> > The DMA API is preferred.
>> >
>> > Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Vlad's testing with this patch were finished successfully.
> 
> Thanks Fujita!
> Acked-by: Vladislav Zolotarov <vladz@broadcom.com>
> Acked-by: Eilon Greenstein <eilong@broadcom.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] bnx2: use the dma state API instead of the pci equivalents
From: David Miller @ 2010-04-08  4:05 UTC (permalink / raw)
  To: fujita.tomonori; +Cc: netdev, mchan
In-Reply-To: <20100402115025A.fujita.tomonori@lab.ntt.co.jp>

From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Fri, 2 Apr 2010 11:56:57 +0900

> The DMA API is preferred.
> 
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>

Applied.

^ permalink raw reply

* Re: [PATCHv2] virtio-net: move sg off stack
From: David Miller @ 2010-04-08  4:01 UTC (permalink / raw)
  To: mst; +Cc: rusty, jpirko, xma, netdev, linux-kernel
In-Reply-To: <20100404130741.GA7500@redhat.com>

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 4 Apr 2010 16:07:41 +0300

> Move sg structure off stack and into virtnet_info structure.
> This helps remove extra sg_init_table calls as well as reduce
> stack usage.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Tested-by: Michael S. Tsirkin <mst@redhat.com>

Applied to net-next-2.6, thanks Michael.

^ permalink raw reply

* Re: [PATCH 2/2] benet: fix the misusage of zero dma address
From: David Miller @ 2010-04-08  3:59 UTC (permalink / raw)
  To: sathyap; +Cc: fujita.tomonori, subbus, sarveshwarb, ajitk, netdev
In-Reply-To: <20100405082202.GB32671@serverengines.com>

From: Sathya Perla <sathyap@serverengines.com>
Date: Mon, 5 Apr 2010 13:52:02 +0530

> On 05/04/10 16:40 +0900, FUJITA Tomonori wrote:
>> > > +		wrb->frag_len = 0;
>> > Why does wrb->frag_len need to be reset here?
>> > In the TX path, it is set to the proper value for data wrbs and zero
>> > for dummy and hdr wrbs.
>> 
>> I guess that I misunderstood why unmap_tx_frag() checks a dma address.
>> The checking is necessary to avoid calling pci_unamp_* API for dummy
>> hdr wrbs?
> Yes.
>> 
>> Anyway, if wrb->frag_len doesn't need to be reset here, the following
>> patch is ok?
> Yes. Thanks.
> 
> Acked-by: Sathya Perla <sathyap@serverengines.com>

Applied to net-next-2.6

^ permalink raw reply

* Re: [PATCH 1/2] benet: use the dma state API instead of the pci equivalents
From: David Miller @ 2010-04-08  3:59 UTC (permalink / raw)
  To: sathyap; +Cc: fujita.tomonori, subbus, sarveshwarb, ajitk, netdev
In-Reply-To: <20100405090457.GA2541@serverengines.com>

From: Sathya Perla <sathyap@serverengines.com>
Date: Mon, 5 Apr 2010 14:34:57 +0530

> Thanks.
> 
> Acked-by: Sathya Perla <sathyap@serverengines.com>

Applied to net-next-2.6

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox