Netdev List
 help / color / mirror / Atom feed
* RE: [E1000-devel] [PATCH] e1000: the power down when running ifdown command
From: Allan, Bruce W @ 2009-11-04 17:57 UTC (permalink / raw)
  To: Stephen Hemminger, Naohiro Ooiwa
  Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
	Brandeburg, Jesse, Ronciak, John, Kirsher, Jeffrey T,
	Andrew Morton, svaidy@linux.vnet.ibm.com, davem@davemloft.net
In-Reply-To: <20091104080846.5bf4d225@nehalam>

FWIW, in e1000e the PHY is already powered down when the interface is brought down if WoL and manageability are disabled.  There is an issue where the PHY remains powered on when the driver is removed for which I have a patch already queued up here at Intel.

>-----Original Message-----
>From: Stephen Hemminger [mailto:shemminger@vyatta.com]
>Sent: Wednesday, November 04, 2009 8:09 AM
>To: Naohiro Ooiwa
>Cc: e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; Brandeburg,
>Jesse; Ronciak, John; Kirsher, Jeffrey T; Andrew Morton;
>svaidy@linux.vnet.ibm.com; davem@davemloft.net
>Subject: Re: [E1000-devel] [PATCH] e1000: the power down when running
>ifdown command
>
>On Wed, 04 Nov 2009 19:23:43 +0900
>Naohiro Ooiwa <nooiwa@miraclelinux.com> wrote:
>
>> Naohiro Ooiwa wrote:
>> > Stephen Hemminger wrote:
>> >> On Sat, 31 Oct 2009 18:39:52 +0900
>> >> Naohiro Ooiwa <nooiwa@miraclelinux.com> wrote:
>> >>
>> >> Does this work with Wake On Lan?
>> >
>> > Yes, it works WOL.
>>
>> Sorry, I made a mistake.
>> The WOL doesn't work when my patch applied to kernel.
>> I wasn't myself.
>>
>> I consider the WOL and I will resent the patch.
>> Thank you for your point.
>>
>>
>> thanks,
>> Naohiro Ooiwa
>
>
>Good, thank you for checking. I like the idea of powering down the
>PHY. Some of the drivers have shutdown hooks to power PHY back on
>during shutdown to enable WOL.
>
>
>--
>
>--------------------------------------------------------------------------
>----
>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-
>Day
>trial. Simplify your report design, integration and deployment - and focus
>on
>what you do best, core application coding. Discover what's new with
>Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>_______________________________________________
>E1000-devel mailing list
>E1000-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/e1000-devel

^ permalink raw reply

* Re: [PATCH 03/25] mlx4_core: add multi-function communication channel
From: Roland Dreier @ 2009-11-04 18:04 UTC (permalink / raw)
  To: Yevgeny Petrilin
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
	liranl-VPRAkNaXOzVS1MOuV/RT9w, tziporet-VPRAkNaXOzVS1MOuV/RT9w
In-Reply-To: <4AF19E14.5070107-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>


 > --- a/drivers/net/mlx4/cmd.c
 > +++ b/drivers/net/mlx4/cmd.c
 > @@ -41,6 +41,7 @@
 >  #include <asm/io.h>
 >  
 >  #include "mlx4.h"
 > +#include "en_port.h"

Why does core mlx4 command handling end up depending on stuff from en_port.h?

 > +	__be32 status = readl(&priv->mfunc.comm->slave_read);

This can't be endian-clean, can it?  What does sparse with
-D__CHECK_ENDIAN__ say?

 > +	queue_delayed_work(priv->mfunc.comm_wq, &priv->mfunc.comm_work,
 > +						polled ? HZ / 1000 : HZ / 10);

So this is always running at least 10 times a second?  That's a lot of
wakeups on an idle system.  Is there no way to make this event-driven?

And HZ/1000 is going to be 0 if HZ is less than 1000 ... so this is just
going to run continuously in the polling case.

 > +	/* Write command */
 > +	if (cmd == MLX4_COMM_CMD_RESET)
 > +		priv->cmd.comm_toggle = 0;
 > +	else if (++priv->cmd.comm_toggle > 2)
 > +		priv->cmd.comm_toggle = 1;

Is this right?  comm_toggle goes 0, 1, 2, 1, 2, ...?

 > +static struct mlx4_cmd_info {
 > +	u8 opcode;
 > +	u8 has_inbox;
 > +	u8 has_outbox;
 > +	u8 out_is_imm;
 > +	int (*verify)(struct mlx4_dev *dev, int slave, struct mlx4_vhcr *vhcr,
 > +					    struct mlx4_cmd_mailbox *inbox);
 > +	int (*wrapper)(struct mlx4_dev *dev, int slave, struct mlx4_vhcr *vhcr,
 > +					     struct mlx4_cmd_mailbox *inbox,
 > +					     struct mlx4_cmd_mailbox *outbox);
 > +} cmd_info[] = {
 > +	{MLX4_CMD_QUERY_FW,        0, 1, 0, NULL, NULL},
 > +	{MLX4_CMD_QUERY_ADAPTER,   0, 1, 0, NULL, NULL},

This big structure would be better with designated initializers.  Also
instead of u8 for the flags bool would be better probably.  Then it
becomes more self documenting, ie

	{ .opcode = MLX4_CMD_QUERY_FW, .has_outbox = true }, ...

 > +struct mlx4_vhcr {
 > +	u64 in_param;
 > +	u64 out_param;
 > +	u32 in_modifier;
 > +	u32 timeout;
 > +	u16 op;
 > +	u16 token;
 > +	u8 op_modifier;
 > +	int errno;
 > +};

trivial but can you use tabs to line up the structure field names the
way the rest of the mlx4 declarations do?

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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] ems_usb: Fix byte order issues on big endian machines
From: Wolfgang Grandegger @ 2009-11-04 18:06 UTC (permalink / raw)
  To: Sebastian Haas
  Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
	netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091104154824.18199.15573.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>

Sebastian Haas wrote:
> CPC-USB is using a ARM7 core with little endian byte order. The "id" field
> in can_msg needs byte order conversion from/to CPU byte order.
> 
> Signed-off-by: Sebastian Haas <haas-zsNKPWJ8Pib6hrUXjxyGrA@public.gmane.org>

Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>

Thanks.

Wolfgang.

^ permalink raw reply

* Re: [PATCHv6 1/3] tun: export underlying socket
From: Arnd Bergmann @ 2009-11-04 18:09 UTC (permalink / raw)
  To: virtualization
  Cc: Michael S. Tsirkin, netdev, kvm, linux-kernel, mingo, linux-mm,
	akpm, hpa, gregory.haskins, Rusty Russell, s.hetze
In-Reply-To: <200911031312.33580.arnd@arndb.de>

On Tuesday 03 November 2009, Arnd Bergmann wrote:
> > index 3f5fd52..404abe0 100644
> > --- a/include/linux/if_tun.h
> > +++ b/include/linux/if_tun.h
> > @@ -86,4 +86,18 @@ struct tun_filter {
> >         __u8   addr[0][ETH_ALEN];
> >  };
> >  
> > +#ifdef __KERNEL__
> > +#if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
> > +struct socket *tun_get_socket(struct file *);
> > +#else
> > +#include <linux/err.h>
> > +#include <linux/errno.h>
> > +struct file;
> > +struct socket;
> > +static inline struct socket *tun_get_socket(struct file *f)
> > +{
> > +       return ERR_PTR(-EINVAL);
> > +}
> > +#endif /* CONFIG_TUN */
> > +#endif /* __KERNEL__ */
> >  #endif /* __IF_TUN_H */
> 
> Is this a leftover from testing? Exporting the function for !__KERNEL__
> seems pointless.
> 

Michael, you didn't reply on this comment and the code is still there in v8.
Do you actually need this? What for?

	Arnd <><

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* [PATCH net-next-2.6] decnet: avoid touching device refcount in dn_dev_by_index()
From: Eric Dumazet @ 2009-11-04 18:15 UTC (permalink / raw)
  To: David S. Miller; +Cc: Linux Netdev List

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 net/decnet/dn_dev.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/decnet/dn_dev.c b/net/decnet/dn_dev.c
index 6e1f085..d566e98 100644
--- a/net/decnet/dn_dev.c
+++ b/net/decnet/dn_dev.c
@@ -600,15 +600,17 @@ static void dn_dev_check_default(struct net_device *dev)
 		dev_put(dev);
 }
 
+/*
+ * Called with RTNL
+ */
 static struct dn_dev *dn_dev_by_index(int ifindex)
 {
 	struct net_device *dev;
 	struct dn_dev *dn_dev = NULL;
-	dev = dev_get_by_index(&init_net, ifindex);
-	if (dev) {
+
+	dev = __dev_get_by_index(&init_net, ifindex);
+	if (dev)
 		dn_dev = dev->dn_ptr;
-		dev_put(dev);
-	}
 
 	return dn_dev;
 }

^ permalink raw reply related

* Re: [PATCH 05/25] mlx4_core: add slave resource allocation
From: Roland Dreier @ 2009-11-04 18:19 UTC (permalink / raw)
  To: Yevgeny Petrilin; +Cc: linux-rdma, netdev, liranl, tziporet
In-Reply-To: <4AF19E1E.4000102@mellanox.co.il>


 > +	u32 param1 = *((u32 *) &vhcr->in_param);
 > +	u32 param2 = *(((u32 *) &vhcr->in_param) + 1);

Is this endian clean?

 - R.

^ permalink raw reply

* Re: [RFC-PATCH] dhcp provisioning support in cxgb3i
From: Rakesh Ranjan @ 2009-11-04 18:24 UTC (permalink / raw)
  To: Mike Christie
  Cc: davem, James Bottomley, Karen Xie, open-iscsi@googlegroups.com,
	LKML, linux-scsi@vger.kernel.org, netdev, Rakesh Ranjan
In-Reply-To: <4AEF6FC4.6060208@cs.wisc.edu>

Mike Christie wrote:
> Rakesh Ranjan wrote:
>> Mike Christie wrote:
>>> Rakesh Ranjan wrote:
>>>> Hi Mike,
>>>>
>>>> Herein attached patches for having dhcp provisioning support in
>>>> cxgb3i. I have added one new iscsi netlink message
>>>> ISCSI_UEVENT_REQ_IPCONF. 
>>>
>>> Is the idea to have iscsid/uip send down this msg?
>>>
>>> Was it not possible to hook in more like how bnx2i does dhcp?
>>
>> yep, idea is to have iscsid send down ISCSI_UEVENT_REQ_IPCONF msg.
>> bnx2i approach in our case for at least T3 is not feasible.
>>
> 
> I think adding DHCP in the kernel is getting a little crazy :) If we go
> down this path, I agree with the other person that stated it should at
> least be generic.

Hi Mike,

What do you mean be generic ? Do you want to have a generic interface
for DHCP handler that could be part of libiscsi and could be used by
other LLD's.

Regards
Rakesh Ranjan

^ permalink raw reply

* Re: [PATCH net-next-2.6] decnet: avoid touching device refcount in dn_dev_by_index()
From: David Miller @ 2009-11-04 18:59 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AF1C4B2.6090802@gmail.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 04 Nov 2009 19:15:14 +0100

> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied, thanks Eric.

^ permalink raw reply

* Re: [PATCHv6 1/3] tun: export underlying socket
From: Michael S. Tsirkin @ 2009-11-04 19:05 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: virtualization, netdev, kvm, linux-kernel, mingo, linux-mm, akpm,
	hpa, gregory.haskins, Rusty Russell, s.hetze
In-Reply-To: <200911041909.06054.arnd@arndb.de>

On Wed, Nov 04, 2009 at 07:09:05PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 November 2009, Arnd Bergmann wrote:
> > > index 3f5fd52..404abe0 100644
> > > --- a/include/linux/if_tun.h
> > > +++ b/include/linux/if_tun.h
> > > @@ -86,4 +86,18 @@ struct tun_filter {
> > >         __u8   addr[0][ETH_ALEN];
> > >  };
> > >  
> > > +#ifdef __KERNEL__
> > > +#if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
> > > +struct socket *tun_get_socket(struct file *);
> > > +#else
> > > +#include <linux/err.h>
> > > +#include <linux/errno.h>
> > > +struct file;
> > > +struct socket;
> > > +static inline struct socket *tun_get_socket(struct file *f)
> > > +{
> > > +       return ERR_PTR(-EINVAL);
> > > +}
> > > +#endif /* CONFIG_TUN */
> > > +#endif /* __KERNEL__ */
> > >  #endif /* __IF_TUN_H */
> > 
> > Is this a leftover from testing? Exporting the function for !__KERNEL__
> > seems pointless.
> > 
> 
> Michael, you didn't reply on this comment and the code is still there in v8.
> Do you actually need this? What for?
> 
> 	Arnd <><

Sorry, missed the question. If you look closely it is not exported for
!__KERNEL__ at all.  The stub is for when CONFIG_TUN is undefined.
Maybe I'll add a comment near #else, even though this is a bit strange
since the #if is just 2 lines above it.

-- 
MST

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [PATCHv7 3/3] vhost_net: a kernel-level virtio server
From: Michael S. Tsirkin @ 2009-11-04 19:06 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Gregory Haskins, Eric Dumazet, netdev, virtualization, kvm,
	linux-kernel, mingo, linux-mm, akpm, hpa, Rusty Russell, s.hetze
In-Reply-To: <20091104172542.GC6736@linux.vnet.ibm.com>

On Wed, Nov 04, 2009 at 09:25:42AM -0800, Paul E. McKenney wrote:
> (Sorry, but, as always, I could not resist!)
> 
> 							Thanx, Paul

Thanks Paul!
Jonathan: are you reading this?
Another one for your quotes of the week collection :)

-- 
MST

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [RFC-PATCH] dhcp provisioning support in cxgb3i
From: Stephen Hemminger @ 2009-11-04 19:09 UTC (permalink / raw)
  To: Rakesh Ranjan
  Cc: Mike Christie, davem, James Bottomley, Karen Xie,
	open-iscsi@googlegroups.com, LKML, linux-scsi@vger.kernel.org,
	netdev, Rakesh Ranjan
In-Reply-To: <4AF1C6C7.80103@chelsio.com>

On Wed, 04 Nov 2009 23:54:07 +0530
Rakesh Ranjan <rakesh@chelsio.com> wrote:

> Mike Christie wrote:
> > Rakesh Ranjan wrote:
> >> Mike Christie wrote:
> >>> Rakesh Ranjan wrote:
> >>>> Hi Mike,
> >>>>
> >>>> Herein attached patches for having dhcp provisioning support in
> >>>> cxgb3i. I have added one new iscsi netlink message
> >>>> ISCSI_UEVENT_REQ_IPCONF. 
> >>>
> >>> Is the idea to have iscsid/uip send down this msg?
> >>>
> >>> Was it not possible to hook in more like how bnx2i does dhcp?
> >>
> >> yep, idea is to have iscsid send down ISCSI_UEVENT_REQ_IPCONF msg.
> >> bnx2i approach in our case for at least T3 is not feasible.
> >>
> > 
> > I think adding DHCP in the kernel is getting a little crazy :) If we go
> > down this path, I agree with the other person that stated it should at
> > least be generic.
> 
> Hi Mike,
> 
> What do you mean be generic ? Do you want to have a generic interface
> for DHCP handler that could be part of libiscsi and could be used by
> other LLD's.

Is there anyway to make existing code (in net/ipv4/ipconfig.c) more generic
and useful for both?

^ permalink raw reply

* [PATCH net-next-2.6] bridge: remove dev_put() in add_del_if()
From: Eric Dumazet @ 2009-11-04 19:09 UTC (permalink / raw)
  To: David S. Miller; +Cc: Linux Netdev List, Stephen Hemminger

add_del_if() is called with RTNL, we can use __dev_get_by_index()
instead of [dev_get_by_index() + dev_put()]

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 net/bridge/br_ioctl.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c
index 6a6433d..2af6e4a 100644
--- a/net/bridge/br_ioctl.c
+++ b/net/bridge/br_ioctl.c
@@ -81,6 +81,7 @@ static int get_fdb_entries(struct net_bridge *br, void __user *userbuf,
 	return num;
 }
 
+/* called with RTNL */
 static int add_del_if(struct net_bridge *br, int ifindex, int isadd)
 {
 	struct net_device *dev;
@@ -89,7 +90,7 @@ static int add_del_if(struct net_bridge *br, int ifindex, int isadd)
 	if (!capable(CAP_NET_ADMIN))
 		return -EPERM;
 
-	dev = dev_get_by_index(dev_net(br->dev), ifindex);
+	dev = __dev_get_by_index(dev_net(br->dev), ifindex);
 	if (dev == NULL)
 		return -EINVAL;
 
@@ -98,7 +99,6 @@ static int add_del_if(struct net_bridge *br, int ifindex, int isadd)
 	else
 		ret = br_del_if(br, dev);
 
-	dev_put(dev);
 	return ret;
 }
 

^ permalink raw reply related

* Re: [PATCHv7 3/3] vhost_net: a kernel-level virtio server
From: Gregory Haskins @ 2009-11-04 19:12 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Paul E. McKenney, Eric Dumazet, netdev, virtualization, kvm,
	linux-kernel, mingo, linux-mm, akpm, hpa, Rusty Russell, s.hetze
In-Reply-To: <20091104190609.GB772@redhat.com>

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

Michael S. Tsirkin wrote:
> On Wed, Nov 04, 2009 at 09:25:42AM -0800, Paul E. McKenney wrote:
>> (Sorry, but, as always, I could not resist!)
>>
>> 							Thanx, Paul
> 
> Thanks Paul!
> Jonathan: are you reading this?
> Another one for your quotes of the week collection :)
> 

I second that.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

^ permalink raw reply

* Re: [PATCHv8 0/3] vhost: a kernel-level virtio server
From: Gregory Haskins @ 2009-11-04 19:15 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: netdev, virtualization, kvm, linux-kernel, mingo, linux-mm, akpm,
	hpa, Rusty Russell, s.hetze, Daniel Walker, Eric Dumazet
In-Reply-To: <20091104162339.GA311@redhat.com>

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

Michael S. Tsirkin wrote:
> On Wed, Nov 04, 2009 at 11:02:15AM -0500, Gregory Haskins wrote:
>> Michael S. Tsirkin wrote:
>>> Ok, I think I've addressed all comments so far here.
>>> Rusty, I'd like this to go into linux-next, through your tree, and
>>> hopefully 2.6.33.  What do you think?
>> I think the benchmark data is a prerequisite for merge consideration, IMO.
> 
> Shirley Ma was kind enough to send me some measurement results showing
> how kernel level acceleration helps speed up you can find them here:
> http://www.linux-kvm.org/page/VhostNet

Thanks for the pointers.  I will roll your latest v8 code into our test
matrix.  What kernel/qemu trees do they apply to?

-Greg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

^ permalink raw reply

* Re: REGRESSION: On 2.6.32-rc5 the firmware hangs, and the nic is unusable.
From: Dhananjay Phadke @ 2009-11-04 19:15 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: netdev@vger.kernel.org, Ameen Rahman, Amit Salecha
In-Reply-To: <m1tyxaagal.fsf@fess.ebiederm.org>



Eric W. Biederman wrote:
> On 2.6.31.5 I get:
> ethtool -i eth0
> driver: netxen_nic
> version: 4.0.30
> firmware-version: 4.0.305
> bus-info: 0000:06:00.0
> 

Agree, 2.6.31 window missed bonding (mac addr setup) fixes.

> And everything works except bonding.
> 
> On 2.6.32-rc5 I dhcp I get an IP
> there is a sanity test ping.

> 
> Then the driver reports a firmware hang and
> the interface goes down and I am dead in the water.
> 

> I'm a bit frustrated with this as it seems with each kernel release
> the driver gets a little bit less usable.
> 
> Have I given you enough information to track this down?

This can be fixed in next rc patch of 2.6.32, if I get enough info to debug.

Could you provide full dmesg, so that I can see what's going on around 
firmware hang message? Also provide your test details (bonding / 
whatever configured).

Thanks,
-Dhananjay

^ permalink raw reply

* Re: [PATCHv8 0/3] vhost: a kernel-level virtio server
From: Michael S. Tsirkin @ 2009-11-04 19:19 UTC (permalink / raw)
  To: Gregory Haskins
  Cc: netdev, virtualization, kvm, linux-kernel, mingo, linux-mm, akpm,
	hpa, Rusty Russell, s.hetze, Daniel Walker, Eric Dumazet
In-Reply-To: <4AF1D2DE.10705@gmail.com>

On Wed, Nov 04, 2009 at 02:15:42PM -0500, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > On Wed, Nov 04, 2009 at 11:02:15AM -0500, Gregory Haskins wrote:
> >> Michael S. Tsirkin wrote:
> >>> Ok, I think I've addressed all comments so far here.
> >>> Rusty, I'd like this to go into linux-next, through your tree, and
> >>> hopefully 2.6.33.  What do you think?
> >> I think the benchmark data is a prerequisite for merge consideration, IMO.
> > 
> > Shirley Ma was kind enough to send me some measurement results showing
> > how kernel level acceleration helps speed up you can find them here:
> > http://www.linux-kvm.org/page/VhostNet
> 
> Thanks for the pointers.  I will roll your latest v8 code into our test
> matrix.  What kernel/qemu trees do they apply to?
> 
> -Greg
> 


kernel 2.6.32-rc6, qemu-kvm 47e465f031fc43c53ea8f08fa55cc3482c6435c8.
You can also use my development git trees if you like.

kernel:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost
userspace:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git vhost

Please note I rebase especially userspace tree now and when.

-- 
MST

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [PATCH net-next-2.6] bridge: remove dev_put() in add_del_if()
From: Stephen Hemminger @ 2009-11-04 19:40 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4AF1D153.5040309@gmail.com>

On Wed, 04 Nov 2009 20:09:07 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> add_del_if() is called with RTNL, we can use __dev_get_by_index()
> instead of [dev_get_by_index() + dev_put()]
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
>  net/bridge/br_ioctl.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c
> index 6a6433d..2af6e4a 100644
> --- a/net/bridge/br_ioctl.c
> +++ b/net/bridge/br_ioctl.c
> @@ -81,6 +81,7 @@ static int get_fdb_entries(struct net_bridge *br, void __user *userbuf,
>  	return num;
>  }
>  
> +/* called with RTNL */
>  static int add_del_if(struct net_bridge *br, int ifindex, int isadd)
>  {
>  	struct net_device *dev;
> @@ -89,7 +90,7 @@ static int add_del_if(struct net_bridge *br, int ifindex, int isadd)
>  	if (!capable(CAP_NET_ADMIN))
>  		return -EPERM;
>  
> -	dev = dev_get_by_index(dev_net(br->dev), ifindex);
> +	dev = __dev_get_by_index(dev_net(br->dev), ifindex);
>  	if (dev == NULL)
>  		return -EINVAL;
>  
> @@ -98,7 +99,6 @@ static int add_del_if(struct net_bridge *br, int ifindex, int isadd)
>  	else
>  		ret = br_del_if(br, dev);
>  
> -	dev_put(dev);
>  	return ret;
>  }
>  

As part of the general ref count purge sure.
Acked-by: Stephen Hemminger <shemminger@vyatta.com>

-- 

^ permalink raw reply

* Re: [PATCH net-next-2.6] bridge: remove dev_put() in add_del_if()
From: Eric Dumazet @ 2009-11-04 19:43 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <20091104114020.5a2aef2c@nehalam>

Stephen Hemminger a écrit :
> 
> As part of the general ref count purge sure.
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
> 

Yes, sure... but nf_queue.c is such an abuser that I doubt we
really can make dev_put() doing the atomic_dec_test() one day...

^ permalink raw reply

* Re: [PATCH 01/25] mlx4_core: identify function as pf or vf
From: Roland Dreier @ 2009-11-04 19:45 UTC (permalink / raw)
  To: Yevgeny Petrilin
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
	liranl-VPRAkNaXOzVS1MOuV/RT9w, tziporet-VPRAkNaXOzVS1MOuV/RT9w
In-Reply-To: <4AF19E07.7040702-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>

Just noticed that all the patches I looked at have:

 > From: Yevgeny Petrilin <yevgenyp-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>

but only:

 > Signed-off-by: Liran Liss <liranl-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>

I guess Liran is actually the real author?  in this case, you should
add a line like:

From: Liran Liss <liranl-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>

in the body of the email message, and add your own signed-off-by line
after Liran's (since you are in the chain of people handling the patch).

 - R.


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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

* [PATCH net-next-2.6] netfilter: remove synchronize_net() calls in ip_queue/ip6_queue
From: Eric Dumazet @ 2009-11-04 19:47 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Linux Netdev List, Netfilter Developers

nf_unregister_queue_handlers() already does a synchronize_rcu()
call, we dont need to do it again in callers.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 net/ipv4/netfilter/ip_queue.c  |    2 +-
 net/ipv6/netfilter/ip6_queue.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/netfilter/ip_queue.c b/net/ipv4/netfilter/ip_queue.c
index c156db2..9811a45 100644
--- a/net/ipv4/netfilter/ip_queue.c
+++ b/net/ipv4/netfilter/ip_queue.c
@@ -622,7 +622,7 @@ cleanup_netlink_notifier:
 static void __exit ip_queue_fini(void)
 {
 	nf_unregister_queue_handlers(&nfqh);
-	synchronize_net();
+
 	ipq_flush(NULL, 0);
 
 #ifdef CONFIG_SYSCTL
diff --git a/net/ipv6/netfilter/ip6_queue.c b/net/ipv6/netfilter/ip6_queue.c
index 1cf3f0c..a82016f 100644
--- a/net/ipv6/netfilter/ip6_queue.c
+++ b/net/ipv6/netfilter/ip6_queue.c
@@ -625,7 +625,7 @@ cleanup_netlink_notifier:
 static void __exit ip6_queue_fini(void)
 {
 	nf_unregister_queue_handlers(&nfqh);
-	synchronize_net();
+
 	ipq_flush(NULL, 0);
 
 #ifdef CONFIG_SYSCTL

^ permalink raw reply related

* Re: [PATCH 16/25] mlx4_core: boot sriov
From: Roland Dreier @ 2009-11-04 19:55 UTC (permalink / raw)
  To: Yevgeny Petrilin; +Cc: linux-rdma, netdev, liranl, tziporet
In-Reply-To: <4AF19E5D.1060806@mellanox.co.il>


 > +	/* Detect if this device is a virtual function */
 > +	switch (id->device) {
 > +	case 0x6341:
 > +	case 0x634b:
 > +	case 0x6733:
 > +	case 0x673d:
 > +	case 0x6369:
 > +	case 0x6751:
 > +	case 0x6765:

This isn't be maintainable or sane.  How about using driver_data in the
PCI device table?

 > +#ifdef CONFIG_PCI_IOV
 > +		if (sr_iov) {

Can we avoid a lot of these ifdefs by just doing

#else
#define sr_iov	0
#endif /* CONFIG_PCI_IOV */

at the beginning and letting the IOV code be optimized away?

 - R.

^ permalink raw reply

* [PATCH net-next-2.6] netlabel: remove dev_put() calls
From: Eric Dumazet @ 2009-11-04 20:03 UTC (permalink / raw)
  To: David S. Miller; +Cc: Linux Netdev List

Use dev_get_by_name_rcu() to avoid dev_put() calls,
in sections already inside a rcu_read_lock()

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 net/netlabel/netlabel_unlabeled.c |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
index fb357f0..3dfe2ba 100644
--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -472,13 +472,12 @@ int netlbl_unlhsh_add(struct net *net,
 
 	rcu_read_lock();
 	if (dev_name != NULL) {
-		dev = dev_get_by_name(net, dev_name);
+		dev = dev_get_by_name_rcu(net, dev_name);
 		if (dev == NULL) {
 			ret_val = -ENODEV;
 			goto unlhsh_add_return;
 		}
 		ifindex = dev->ifindex;
-		dev_put(dev);
 		iface = netlbl_unlhsh_search_iface(ifindex);
 	} else {
 		ifindex = 0;
@@ -737,13 +736,12 @@ int netlbl_unlhsh_remove(struct net *net,
 
 	rcu_read_lock();
 	if (dev_name != NULL) {
-		dev = dev_get_by_name(net, dev_name);
+		dev = dev_get_by_name_rcu(net, dev_name);
 		if (dev == NULL) {
 			ret_val = -ENODEV;
 			goto unlhsh_remove_return;
 		}
 		iface = netlbl_unlhsh_search_iface(dev->ifindex);
-		dev_put(dev);
 	} else
 		iface = rcu_dereference(netlbl_unlhsh_def);
 	if (iface == NULL) {

^ permalink raw reply related

* Re: [PATCH 19/25] mlx4: Randomizing mac addresses for slaves
From: Roland Dreier @ 2009-11-04 20:04 UTC (permalink / raw)
  To: Yevgeny Petrilin
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
	liranl-VPRAkNaXOzVS1MOuV/RT9w, tziporet-VPRAkNaXOzVS1MOuV/RT9w
In-Reply-To: <4AF19E69.8070605-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>


 > +#define MLX4_MAC_HEAD		0x2c9000000ULL
 > +			random_ether_addr(rand_mac);
 > +			caps->def_mac[i] = MLX4_MAC_HEAD | rand_mac[0] |
 > +				((u64)(rand_mac[1]) << 8) | ((u64)(rand_mac[2]) << 16);

Is this a good idea?  You're basically choosing 24 random bits within
your OUI... seems the chance of collision with another MAC used on the
same network is high enough that it could easily happen in practice on a
moderately big network.  Can you pick a reserved range or something?

Also I'm not sure if there's much point in using random_ether_addr if
you're going to override the high order part anyway, since
random_ether_addr just makes sure it doesn't pick a multicast address.

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 net-next-2.6] netfilter: remove synchronize_net() calls in ip_queue/ip6_queue
From: Patrick McHardy @ 2009-11-04 20:15 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Linux Netdev List, Netfilter Developers
In-Reply-To: <4AF1DA57.8080202@gmail.com>

Eric Dumazet wrote:
> nf_unregister_queue_handlers() already does a synchronize_rcu()
> call, we dont need to do it again in callers.

Applied, thanks Eric.

^ permalink raw reply

* [PATCH] appletalk/ddp.c: Neaten checksum function
From: Joe Perches @ 2009-11-04 20:26 UTC (permalink / raw)
  To: netdev; +Cc: Arnaldo Carvalho de Melo, David S. Miller

atalk_sum_partial can now use the rol16 function in bitops.h

Signed-off-by: Joe Perches <joe@perches.com>

diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index abe3801..e6903db 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -922,13 +922,8 @@ static unsigned long atalk_sum_partial(const unsigned char *data,
 {
 	/* This ought to be unwrapped neatly. I'll trust gcc for now */
 	while (len--) {
-		sum += *data;
-		sum <<= 1;
-		if (sum & 0x10000) {
-			sum++;
-			sum &= 0xffff;
-		}
-		data++;
+		sum += *data++;
+		sum = rol16(sum, 1);
 	}
 	return sum;
 }



^ permalink raw reply related


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