* Good News!
From: D.S.T.V Company @ 2012-07-02 17:26 UTC (permalink / raw)
Your email has won you £950,000.00GBP from the D.S.T.V Company. For Claims send
us your: Full name/Home Address/ Age/Sex/Occupation/Country.
Mrs. Elaine Raymond
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [PATCH net-next 09/15] net: bus: Add garbage collector for AF_BUS sockets.
From: Alban Crequy @ 2012-07-03 12:11 UTC (permalink / raw)
To: Ben Hutchings
Cc: Vincent Sanders, netdev, linux-kernel, David S. Miller,
Javier Martinez Canillas
In-Reply-To: <1341251063.2590.5.camel@bwh-desktop.uk.solarflarecom.com>
Mon, 2 Jul 2012 18:44:23 +0100,
Ben Hutchings <bhutchings@solarflare.com> wrote :
> On Fri, 2012-06-29 at 17:45 +0100, Vincent Sanders wrote:
> > From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> >
> > This patch adds a garbage collector for AF_BUS sockets.
> [...]
> > +struct sock *bus_get_socket(struct file *filp)
> > +{
> > + struct sock *u_sock = NULL;
> > + struct inode *inode = filp->f_path.dentry->d_inode;
> > +
> > + /*
> > + * Socket ?
> > + */
> > + if (S_ISSOCK(inode->i_mode) && !(filp->f_mode &
> > FMODE_PATH)) {
> > + struct socket *sock = SOCKET_I(inode);
> > + struct sock *s = sock->sk;
> > +
> > + /*
> > + * PF_BUS ?
> > + */
> > + if (s && sock->ops && sock->ops->family == PF_BUS)
> > + u_sock = s;
> > + }
> > + return u_sock;
> > +}
> [...]
>
> What about references cycles involving both AF_BUS and AF_UNIX
> sockets? I think you must either specifically prevent passing AF_UNIX
> sockets through AF_BUS sockets, or make a single garbage collector
> handle them both.
Indeed. Thanks for the feedback.
As far as I know, the current users of fd passing in D-Bus are Bluez
and Ofono and they pass AF_BLUETOOTH sockets. There might be
others, I am not sure what is in the wild. Passing AF_UNIX sockets in
D-Bus would be useful for Telepathy (for Tubes and File Transfer).
So I would like to be able to pass AF_UNIX sockets through AF_BUS
sockets.
I wrote the following small program to test this bug based on the
previous code <https://lkml.org/lkml/2010/11/25/8> referred by commit
25888e30:
http://people.collabora.com/~alban/d/2012/07/fd-passing/cmsg.c
The effect of the bug is to reach the file limit
in /proc/sys/fs/file-max and print "VFS: file-max limit 101771 reached"
even when the maximum of file descriptors per process ("ulimit -n") is
small.
I am not sure what is the best way to fix this. The easiest could be to
move the garbage collector related fields (recursion_level,
gc_candidate, etc.) from struct unix_sock and struct bus_sock to
struct sock and make a generic garbage collector for all sockets.
Best regards,
Alban
^ permalink raw reply
* speed specific port cost calculation in br_if.c and how to make it generic based on 802.1d Table-17-3?
From: Parav.Pandit @ 2012-07-03 12:40 UTC (permalink / raw)
To: netdev; +Cc: Parav.Pandit
Hi,
I am trying to add further support to bridging portion of stack for 40G and 100G speeds.
net/bridge/br_if.c function port_cost() has hard coded values of 2, 4, 19, 100 for speed of 10G, 1G, 100M, 10Mbps respectively.
Comment mentions about based on 802.1d standard.
I am referring to 802.1d-2004 Table 17-3-Port Path Cost values.
It mentions port cost value of 2000, 20000, 200000 respectively for speed of 10G, 1G, 100Mbps respectively.
This makes sense to me as the post cost value is inversely proportional and scalar function of its speed.
Can anyone please guide me on
1. how the current calculation of path/port cost is being done so that I can enhance it for other speeds too in generic way if possible?
2. How can I incorporate for other speed settings in generic way based on 802.1a-2004 spec, Table 17-3?
Current code snippet:
/* Determine initial path cost based on speed.
* using recommendations from 802.1d standard
*
* Since driver might sleep need to not be holding any locks.
*/
static int port_cost(struct net_device *dev)
{
struct ethtool_cmd ecmd;
if (!__ethtool_get_settings(dev, &ecmd)) {
switch (ethtool_cmd_speed(&ecmd)) {
case SPEED_10000:
return 2;
case SPEED_1000:
return 4;
case SPEED_100:
return 19;
case SPEED_10:
return 100;
}
}
/* Old silly heuristics based on name */
if (!strncmp(dev->name, "lec", 3))
return 7;
if (!strncmp(dev->name, "plip", 4))
return 2500;
return 100; /* assume old 10Mbps */
}
Regards,
Parav Pandit
^ permalink raw reply
* RE: [PATCH 1/1] atl1c: fix issue of transmit queue 0 timed out
From: Huang, Xiong @ 2012-07-03 13:04 UTC (permalink / raw)
To: Ren, Cloud, davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: qca-linux-team, nic-devel
In-Reply-To: <1341322056-26582-1-git-send-email-cjren@qca.qualcomm.com>
Cloud, why your patch contains : 'From: Cloud Ren <cjren@qca.qualcomm.com>'
I don't find it in other people's patch.
Doesn't David Miller think your time is wrong ?
> -----Original Message-----
> From: Ren, Cloud
> Sent: Tuesday, July 03, 2012 21:28
> To: davem@davemloft.net; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: qca-linux-team; nic-devel; Ren, Cloud
> Subject: [PATCH 1/1] atl1c: fix issue of transmit queue 0 timed out
>
> From: Cloud Ren <cjren@qca.qualcomm.com>
>
> some people report atl1c could cause system hang with following kernel trace
> info:
> ---------------------------------------
> WARNING: at.../net/sched/sch_generic.c:258 dev_watchdog+0x1db/0x1d0() ...
> NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out ...
> ---------------------------------------
> This is caused by netif_stop_queue calling when cable Link is down.
> So remove netif_stop_queue, because link_watch will take it over.
>
> Signed-off-by: xiong <xiong@qca.qualcomm.com>
> Cc: stable <stable@vger.kernel.org>
> Signed-off-by: Cloud Ren <cjren@qca.qualcomm.com>
> ---
> drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> index 85717cb..7901831 100644
> --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> @@ -261,7 +261,6 @@ static void atl1c_check_link_status(struct
> atl1c_adapter *adapter)
> if ((phy_data & BMSR_LSTATUS) == 0) {
> /* link down */
> netif_carrier_off(netdev);
> - netif_stop_queue(netdev);
> hw->hibernate = true;
> if (atl1c_reset_mac(hw) != 0)
> if (netif_msg_hw(adapter))
> --
> 1.7.7
^ permalink raw reply
* Re: [PATCH 00/13] drivers: hv: kvp
From: Olaf Hering @ 2012-07-03 13:20 UTC (permalink / raw)
To: KY Srinivasan; +Cc: Greg KH, apw, devel, linux-kernel, netdev
In-Reply-To: <426367E2313C2449837CD2DE46E7EAF9155EF399@SN2PRD0310MB382.namprd03.prod.outlook.com>
On Mon, Jul 02, KY Srinivasan wrote:
> While I toyed with your proposal, I feel it just pushes the problem
> out of the daemon code - we would still need to write distro specific
> scripts. If this approach is something that everybody is comfortable
> with, I can take a stab at implementing that.
Until NetworkManager is feature complete and until every distro is using
NetworkManager per default the kvp_daemon needs distro specific code to
get and set network related settings.
Doing it with an external script will simplify debugging and changes to
the code.
Olaf
^ permalink raw reply
* [PATCH 1/1] atl1c: fix issue of transmit queue 0 timed out
From: Ren, Cloud @ 2012-07-03 13:27 UTC (permalink / raw)
To: davem, netdev, linux-kernel; +Cc: qca-linux-team, nic-devel, Cloud Ren
From: Cloud Ren <cjren@qca.qualcomm.com>
some people report atl1c could cause system hang with following
kernel trace info:
---------------------------------------
WARNING: at.../net/sched/sch_generic.c:258 dev_watchdog+0x1db/0x1d0()
...
NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out
...
---------------------------------------
This is caused by netif_stop_queue calling when cable Link is down.
So remove netif_stop_queue, because link_watch will take it over.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Cloud Ren <cjren@qca.qualcomm.com>
---
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 85717cb..7901831 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -261,7 +261,6 @@ static void atl1c_check_link_status(struct atl1c_adapter *adapter)
if ((phy_data & BMSR_LSTATUS) == 0) {
/* link down */
netif_carrier_off(netdev);
- netif_stop_queue(netdev);
hw->hibernate = true;
if (atl1c_reset_mac(hw) != 0)
if (netif_msg_hw(adapter))
--
1.7.7
^ permalink raw reply related
* Re: [PATCH] sctp: refactor sctp_packet_append_chunk and clenup some memory leaks
From: Vlad Yasevich @ 2012-07-03 14:39 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David S. Miller, linux-sctp
In-Reply-To: <1341259164-7396-1-git-send-email-nhorman@tuxdriver.com>
On 07/02/2012 03:59 PM, Neil Horman wrote:
> While doing some recent work on sctp sack bundling I noted that
> sctp_packet_append_chunk was pretty inefficient. Specifially, it was called
> recursively while trying to bundle auth and sack chunks. Because of that we
> call sctp_packet_bundle_sack and sctp_packet_bundle_auth a total of 4 times for
> every call to sctp_packet_append_chunk, knowing that at least 3 of those calls
> will do nothing.
>
> So lets refactor sctp_packet_bundle_auth to have an outer part that does the
> attempted bundling, and an inner part that just does the chunk appends. This
> saves us several calls per iteration that we just don't need.
>
> Also, noticed that the auth and sack bundling fail to free the chunks they
> allocate if the append fails, so make sure we add that in
>
> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
> CC: Vlad Yasevich<vyasevich@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> CC: "David S. Miller"<davem@davemloft.net>
> CC: linux-sctp@vger.kernel.org
> ---
> net/sctp/output.c | 80 +++++++++++++++++++++++++++++++++++------------------
> 1 files changed, 53 insertions(+), 27 deletions(-)
>
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index 0de6cd5..0b62f6c 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -64,6 +64,8 @@
> #include<net/sctp/checksum.h>
>
> /* Forward declarations for private helpers. */
> +static sctp_xmit_t __sctp_packet_append_chunk(struct sctp_packet *packet,
> + struct sctp_chunk *chunk);
> static sctp_xmit_t sctp_packet_can_append_data(struct sctp_packet *packet,
> struct sctp_chunk *chunk);
> static void sctp_packet_append_data(struct sctp_packet *packet,
> @@ -224,7 +226,10 @@ static sctp_xmit_t sctp_packet_bundle_auth(struct sctp_packet *pkt,
> if (!auth)
> return retval;
>
> - retval = sctp_packet_append_chunk(pkt, auth);
> + retval = __sctp_packet_append_chunk(pkt, auth);
> +
> + if (retval != SCTP_XMIT_OK)
> + sctp_chunk_free(auth);
>
> return retval;
> }
> @@ -256,48 +261,31 @@ static sctp_xmit_t sctp_packet_bundle_sack(struct sctp_packet *pkt,
> asoc->a_rwnd = asoc->rwnd;
> sack = sctp_make_sack(asoc);
> if (sack) {
> - retval = sctp_packet_append_chunk(pkt, sack);
> + retval = __sctp_packet_append_chunk(pkt, sack);
> + if (retval != SCTP_XMIT_OK) {
> + sctp_chunk_free(sack);
> + goto out;
> + }
> asoc->peer.sack_needed = 0;
> if (del_timer(timer))
> sctp_association_put(asoc);
> }
> }
> }
> +out:
> return retval;
> }
>
> +
> /* Append a chunk to the offered packet reporting back any inability to do
> * so.
> */
> -sctp_xmit_t sctp_packet_append_chunk(struct sctp_packet *packet,
> - struct sctp_chunk *chunk)
> +static sctp_xmit_t __sctp_packet_append_chunk(struct sctp_packet *packet,
> + struct sctp_chunk *chunk)
> {
> sctp_xmit_t retval = SCTP_XMIT_OK;
> __u16 chunk_len = WORD_ROUND(ntohs(chunk->chunk_hdr->length));
>
> - SCTP_DEBUG_PRINTK("%s: packet:%p chunk:%p\n", __func__, packet,
> - chunk);
> -
> - /* Data chunks are special. Before seeing what else we can
> - * bundle into this packet, check to see if we are allowed to
> - * send this DATA.
> - */
> - if (sctp_chunk_is_data(chunk)) {
> - retval = sctp_packet_can_append_data(packet, chunk);
> - if (retval != SCTP_XMIT_OK)
> - goto finish;
> - }
> -
> - /* Try to bundle AUTH chunk */
> - retval = sctp_packet_bundle_auth(packet, chunk);
> - if (retval != SCTP_XMIT_OK)
> - goto finish;
> -
> - /* Try to bundle SACK chunk */
> - retval = sctp_packet_bundle_sack(packet, chunk);
> - if (retval != SCTP_XMIT_OK)
> - goto finish;
> -
> /* Check to see if this chunk will fit into the packet */
> retval = sctp_packet_will_fit(packet, chunk, chunk_len);
> if (retval != SCTP_XMIT_OK)
> @@ -339,6 +327,44 @@ finish:
> return retval;
> }
>
> +/* Append a chunk to the offered packet reporting back any inability to do
> + * so.
> + */
> +sctp_xmit_t sctp_packet_append_chunk(struct sctp_packet *packet,
> + struct sctp_chunk *chunk)
> +{
> + sctp_xmit_t retval = SCTP_XMIT_OK;
> + __u16 chunk_len = WORD_ROUND(ntohs(chunk->chunk_hdr->length));
> +
> + SCTP_DEBUG_PRINTK("%s: packet:%p chunk:%p\n", __func__, packet,
> + chunk);
> +
> + /* Data chunks are special. Before seeing what else we can
> + * bundle into this packet, check to see if we are allowed to
> + * send this DATA.
> + */
> + if (sctp_chunk_is_data(chunk)) {
> + retval = sctp_packet_can_append_data(packet, chunk);
> + if (retval != SCTP_XMIT_OK)
> + goto finish;
> + }
> +
> + /* Try to bundle AUTH chunk */
> + retval = sctp_packet_bundle_auth(packet, chunk);
> + if (retval != SCTP_XMIT_OK)
> + goto finish;
> +
> + /* Try to bundle SACK chunk */
> + retval = sctp_packet_bundle_sack(packet, chunk);
> + if (retval != SCTP_XMIT_OK)
> + goto finish;
> +
> + retval = __sctp_packet_append_chunk(packet, chunk);
> +
> +finish:
> + return retval;
> +}
> +
> /* All packets are sent to the network through this function from
> * sctp_outq_tail().
> *
^ permalink raw reply
* Re: [PATCH 00/13] drivers: hv: kvp
From: Stephen Hemminger @ 2012-07-03 15:03 UTC (permalink / raw)
To: Olaf Hering; +Cc: Greg KH, apw, devel, linux-kernel, netdev, KY Srinivasan
In-Reply-To: <20120703132049.GA10663@aepfle.de>
> On Mon, Jul 02, KY Srinivasan wrote:
>
> > While I toyed with your proposal, I feel it just pushes the problem
> > out of the daemon code - we would still need to write distro
> > specific
> > scripts. If this approach is something that everybody is
> > comfortable
> > with, I can take a stab at implementing that.
>
> Until NetworkManager is feature complete and until every distro is
> using
> NetworkManager per default the kvp_daemon needs distro specific code
> to
> get and set network related settings.
> Doing it with an external script will simplify debugging and changes
> to
> the code.
Although, Network Manager is a good tool for what it does;
it is not appropriate for every distro. It is overkill
in embedded systems, and it's GUI dependency makes it unmanageable
on servers.
^ permalink raw reply
* Re: [PATCH] etherdevice: introduce broadcast_ether_addr
From: Joe Perches @ 2012-07-03 15:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <1341310587.5131.2.camel@jlt3.sipsolutions.net>
On Tue, 2012-07-03 at 12:16 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> A lot of code has either the memset or an
> inefficient copy from a static array that
> contains the all-ones broadcast address.
> Introduce broadcast_ether_addr() to fill
> an address with all ones, making the code
> clearer and allowing us to get rid of the
> various constant arrays.
[]
> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
[]
> +static inline void broadcast_ether_addr(u8 *addr)
> +{
> + memset(addr, 0xff, ETH_ALEN);
> +}
I think this sort of patch should come as the first
patch in a series with some example conversions.
It might be too easy to confuse is_broadcast_ether_addr
with this function name too. Maybe set_broadcast_ether_addr
might be better.
I really don't see an issue with using memset though.
Everyone already knows what that does.
^ permalink raw reply
* Re: [PATCH] etherdevice: introduce broadcast_ether_addr
From: Johannes Berg @ 2012-07-03 15:16 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, linux-wireless
In-Reply-To: <1341328402.2164.3.camel@joe2Laptop>
On Tue, 2012-07-03 at 08:13 -0700, Joe Perches wrote:
> On Tue, 2012-07-03 at 12:16 +0200, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > A lot of code has either the memset or an
> > inefficient copy from a static array that
> > contains the all-ones broadcast address.
> > Introduce broadcast_ether_addr() to fill
> > an address with all ones, making the code
> > clearer and allowing us to get rid of the
> > various constant arrays.
> []
> > diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> []
> > +static inline void broadcast_ether_addr(u8 *addr)
> > +{
> > + memset(addr, 0xff, ETH_ALEN);
> > +}
>
> I think this sort of patch should come as the first
> patch in a series with some example conversions.
>
> It might be too easy to confuse is_broadcast_ether_addr
> with this function name too. Maybe set_broadcast_ether_addr
> might be better.
Well, it's void so that'd be a compiler error :-)
Also, it's more like random_ether_addr()
johannes
^ permalink raw reply
* RE: [PATCH 00/13] drivers: hv: kvp
From: KY Srinivasan @ 2012-07-03 15:24 UTC (permalink / raw)
To: Ben Hutchings
Cc: Olaf Hering, Greg KH, apw@canonical.com,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20120702195721.GE1894@decadent.org.uk>
> -----Original Message-----
> From: Ben Hutchings [mailto:ben@decadent.org.uk]
> Sent: Monday, July 02, 2012 3:57 PM
> To: KY Srinivasan
> Cc: Olaf Hering; Greg KH; apw@canonical.com; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; linux-kernel@vger.kernel.org;
> netdev@vger.kernel.org
> Subject: Re: [PATCH 00/13] drivers: hv: kvp
>
> On Mon, Jul 02, 2012 at 03:22:25PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Olaf Hering [mailto:olaf@aepfle.de]
> > > Sent: Thursday, June 28, 2012 10:24 AM
> > > To: KY Srinivasan
> > > Cc: Greg KH; apw@canonical.com; devel@linuxdriverproject.org;
> > > virtualization@lists.osdl.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 00/13] drivers: hv: kvp
> > >
> > > On Tue, Jun 26, KY Srinivasan wrote:
> > >
> > > > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > > > The fact that it was Red Hat specific was the main part, this should be
> > > > > done in a standard way, with standard tools, right?
> > > >
> > > > The reason I asked this question was to make sure I address these
> > > > issues in addition to whatever I am debugging now. I use the standard
> > > > tools and calls to retrieve all the IP configuration. As I look at
> > > > each distribution the files they keep persistent IP configuration
> > > > Information is different and that is the reason I chose to start with
> > > > RedHat. If there is a standard way to store the configuration, I will
> > > > do that.
> > >
> > >
> > > KY,
> > >
> > > instead of using system() in kvp_get_ipconfig_info and kvp_set_ip_info,
> > > wouldnt it be easier to call an external helper script which does all
> > > the distribution specific work? Just define some API to pass values to
> > > the script, and something to read values collected by the script back
> > > into the daemon.
> >
> > On the "Get" side I mostly use standard commands/APIs to get all the
> information:
> >
> > 1) IP address information and subnet mask: getifaddrs()
> > 2) DNS information: Parsing /etc/resolv.conf
> > 3) /sbin/ip command for all the routing information
>
> If you're interested in the *current* configuration then (1) and (3)
> are OK but you should really use the rtnetlink API.
>
> However, I suspect that Hyper-V assumes that current and persistent
> configuration are the same thing, which is obviously not true in
> general on Linux. But if NetworkManager is running then you can
> assume they are.
I am only interested in the currently active information. Why do you
recommend the use of rtnetlink API over the "ip" command. If I am not
mistaken, the ip command uses netlink to get the information.
>
> > 4) Parse /etc/sysconfig/network-scripts/ifcfg-ethx for boot protocol
This is the only information that requires parsing a distro specific configuration file. Do
you have any suggestion on how I may get this information in a distro independent way.
> >
> > As you can see, all but the boot protocol is gathered using the "standard distro
> > independent mechanisms. I was looking at NetworkManager cli and it looks
> > like I could gather all the information except the boot protocol information. I am
> > not sure how to gather the boot protocol information in a distro independent
> fashion.
> >
> > On the SET side, I need to persistently store the settings in an appropriate
> configuration
> > file and flush these settings down so that the interface is appropriately
> configured. It is here
> > that I am struggling to find a distro independent way of doing things. It would
> be great if I can
> > use NetworkManager cli (nmcli) to accomplish this. Any help here would be
> greatly appreciated.
> [...]
>
> What was wrong with the NetworkManager D-Bus API I pointed you at?
> I don't see how it makes sense to use nmcli as an API.
I saw some documentation that claimed that nmcli could be used to accomplish
all that can be done with the GUI interface. I am looking for a portable way
to accomplish configuring an interface. If nmcli can do that, I would use it. With
regards to D-BUS API, I took a cursory look at the APIs. I am still evaluating
my options.
Regards,
K. Y
^ permalink raw reply
* RE: [PATCH 00/13] drivers: hv: kvp
From: KY Srinivasan @ 2012-07-03 15:32 UTC (permalink / raw)
To: Olaf Hering
Cc: Greg KH, apw@canonical.com, devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20120703132049.GA10663@aepfle.de>
> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Tuesday, July 03, 2012 9:21 AM
> To: KY Srinivasan
> Cc: Greg KH; apw@canonical.com; devel@linuxdriverproject.org; linux-
> kernel@vger.kernel.org; netdev@vger.kernel.org
> Subject: Re: [PATCH 00/13] drivers: hv: kvp
>
> On Mon, Jul 02, KY Srinivasan wrote:
>
> > While I toyed with your proposal, I feel it just pushes the problem
> > out of the daemon code - we would still need to write distro specific
> > scripts. If this approach is something that everybody is comfortable
> > with, I can take a stab at implementing that.
>
> Until NetworkManager is feature complete and until every distro is using
> NetworkManager per default the kvp_daemon needs distro specific code to
> get and set network related settings.
> Doing it with an external script will simplify debugging and changes to
> the code.
Fair enough. I will keep my current implementation of the GET operation as is since
it is distro independent. On the SET side, I will implement a script as you have suggested.
Regards,
K. Y
>
> Olaf
>
>
^ permalink raw reply
* RE: [PATCH 00/13] drivers: hv: kvp
From: KY Srinivasan @ 2012-07-03 15:35 UTC (permalink / raw)
To: Stephen Hemminger, Olaf Hering
Cc: apw@canonical.com, Greg KH, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org
In-Reply-To: <642e6af6-fc6b-4c54-a4a6-f5bdd38512c7@tahiti.vyatta.com>
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen.hemminger@vyatta.com]
> Sent: Tuesday, July 03, 2012 11:03 AM
> To: Olaf Hering
> Cc: Greg KH; apw@canonical.com; devel@linuxdriverproject.org; linux-
> kernel@vger.kernel.org; netdev@vger.kernel.org; KY Srinivasan
> Subject: Re: [PATCH 00/13] drivers: hv: kvp
>
>
> > On Mon, Jul 02, KY Srinivasan wrote:
> >
> > > While I toyed with your proposal, I feel it just pushes the problem
> > > out of the daemon code - we would still need to write distro
> > > specific
> > > scripts. If this approach is something that everybody is
> > > comfortable
> > > with, I can take a stab at implementing that.
> >
> > Until NetworkManager is feature complete and until every distro is
> > using
> > NetworkManager per default the kvp_daemon needs distro specific code
> > to
> > get and set network related settings.
> > Doing it with an external script will simplify debugging and changes
> > to
> > the code.
>
> Although, Network Manager is a good tool for what it does;
> it is not appropriate for every distro. It is overkill
> in embedded systems, and it's GUI dependency makes it unmanageable
> on servers.
Thanks Stephen. I will retain the code that I currently have for the "GET" side and
I will implement a script as Olaf suggested that can be distro specific to implement
the SET operation.
Regards,
K. Y
^ permalink raw reply
* Re: "ADDRCONF(NETDEV_UP): eth0: link is not ready" with IPv6
From: Arvid Brodin @ 2012-07-03 15:47 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev@vger.kernel.org, Alexey Kuznetsov, Stephen Hemminger,
Nicolas Ferre
In-Reply-To: <1340983473.3066.6.camel@bwh-desktop.uk.solarflarecom.com>
(Added MACB "patch" contact Nicolas Ferre to CC list.)
On 2012-06-29 17:24, Ben Hutchings wrote:
> On Fri, 2012-06-29 at 02:36 +0000, Arvid Brodin wrote:
>> Hi,
>>
>> After 'ip link set eth0 up' on an avr32 board (network driver macb), the device ends up in
>> operational mode "UNKNOWN":
>>
>> # ip link
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
>> link/ether 00:24:74:00:17:9d brd ff:ff:ff:ff:ff:ff
>>
>> Unplugging and plugging in the network cable gets the device to mode "UP".
>>
>> This is a problem for me because I'm trying to use this device as a "slave" device (for a
>> virtual HSR device*) and I need to be able to decide if the slave device is operational or
>> not.
>>
>> Following Stephen's advice here:
>> http://kerneltrap.org/mailarchive/linux-netdev/2008/9/24/3398834 I checked the macb.c code
>> and noticed they do not call netif_carrier_off() neither before register_netdev() nor in
>> dev_open().
>
> It should be called after register_netdev() and before the driver's
> ndo_open implementation returns.
I'm guessing this allows linkwatch to do netif_carrier_on() some time after the dev_open()?
Besides not calling netif_carrier_off() in dev_open(), the Cadence/MACB driver calls
netif_carrier_off() in dev_close(). Is this correct?
How should I handle carrier state for a virtual device? The device should have "carrier"
as long as at least one of the underlying physical interfaces is operational (which I
guess means operational state UP). Would it be correct to watch NETDEV_CHANGE and DOWN/UP
events of the slaves and call netif_carrier_on()/off() on the virtual device depending on
the slaves' states?
>
>> I added the call before register_netdev(), which fixed the problem. However, if I then
>> enable IPv6:
>>
>> # ip link set eth0 up
>> ADDRCONF(NETDEV_UP): eth0: link is not ready
>> eth0: link up (100/Full)
>> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> This looks normal.
Good, that narrows it down a bit.
>
>> Any idea what is happening / what I'm doing wrong? (This is not just cosmetic; is some
>> situations this seems to kill the interface - e.g. ping does not work, down/up does not
>> help...) Things work fine without IPv6 configured.
>
> Perhaps some packets sent automatically by IPv6 are triggering a driver
> bug? Or there is a bug in multicast support, which IPv6 always uses.
>
> Ben.
>
>> *N.B. I'm writing a driver for a network protocol called "High-availability Seamless
>> Redundancy".
>
--
Arvid Brodin | Consultant (Linux)
XDIN AB | Jan Stenbecks Torg 17 | SE-164 40 Kista | Sweden | xdin.com
^ permalink raw reply
* Re: "ADDRCONF(NETDEV_UP): eth0: link is not ready" with IPv6
From: Ben Hutchings @ 2012-07-03 15:55 UTC (permalink / raw)
To: Arvid Brodin
Cc: netdev@vger.kernel.org, Alexey Kuznetsov, Stephen Hemminger,
Nicolas Ferre
In-Reply-To: <4FF313F6.7010600@xdin.com>
On Tue, 2012-07-03 at 15:47 +0000, Arvid Brodin wrote:
> (Added MACB "patch" contact Nicolas Ferre to CC list.)
>
> On 2012-06-29 17:24, Ben Hutchings wrote:
> > On Fri, 2012-06-29 at 02:36 +0000, Arvid Brodin wrote:
> >> Hi,
> >>
> >> After 'ip link set eth0 up' on an avr32 board (network driver macb), the device ends up in
> >> operational mode "UNKNOWN":
> >>
> >> # ip link
> >> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
> >> link/ether 00:24:74:00:17:9d brd ff:ff:ff:ff:ff:ff
> >>
> >> Unplugging and plugging in the network cable gets the device to mode "UP".
> >>
> >> This is a problem for me because I'm trying to use this device as a "slave" device (for a
> >> virtual HSR device*) and I need to be able to decide if the slave device is operational or
> >> not.
> >>
> >> Following Stephen's advice here:
> >> http://kerneltrap.org/mailarchive/linux-netdev/2008/9/24/3398834 I checked the macb.c code
> >> and noticed they do not call netif_carrier_off() neither before register_netdev() nor in
> >> dev_open().
> >
> > It should be called after register_netdev() and before the driver's
> > ndo_open implementation returns.
>
> I'm guessing this allows linkwatch to do netif_carrier_on() some time after the dev_open()?
No, the driver is always responsible for calling
netif_carrier_{on,off}() in a timely manner. link_watch takes care of
stopping the software TX queues if the link goes down.
> Besides not calling netif_carrier_off() in dev_open(), the Cadence/MACB driver calls
> netif_carrier_off() in dev_close(). Is this correct?
Unnecessary but harmless.
> How should I handle carrier state for a virtual device? The device should have "carrier"
> as long as at least one of the underlying physical interfaces is operational (which I
> guess means operational state UP). Would it be correct to watch NETDEV_CHANGE and DOWN/UP
> events of the slaves and call netif_carrier_on()/off() on the virtual device depending on
> the slaves' states?
[...]
That sounds about right.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: "ADDRCONF(NETDEV_UP): eth0: link is not ready" with IPv6
From: Nicolas Ferre @ 2012-07-03 16:15 UTC (permalink / raw)
To: Arvid Brodin, Ben Hutchings
Cc: netdev@vger.kernel.org, Alexey Kuznetsov, Stephen Hemminger,
linux-arm-kernel
In-Reply-To: <4FF313F6.7010600@xdin.com>
On 07/03/2012 05:47 PM, Arvid Brodin :
> (Added MACB "patch" contact Nicolas Ferre to CC list.)
Hi,
(adding linux-arm-kernel)
> On 2012-06-29 17:24, Ben Hutchings wrote:
>> On Fri, 2012-06-29 at 02:36 +0000, Arvid Brodin wrote:
>>> Hi,
>>>
>>> After 'ip link set eth0 up' on an avr32 board (network driver macb), the device ends up in
>>> operational mode "UNKNOWN":
>>>
>>> # ip link
>>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
>>> link/ether 00:24:74:00:17:9d brd ff:ff:ff:ff:ff:ff
>>>
>>> Unplugging and plugging in the network cable gets the device to mode "UP".
>>>
>>> This is a problem for me because I'm trying to use this device as a "slave" device (for a
>>> virtual HSR device*) and I need to be able to decide if the slave device is operational or
>>> not.
>>>
>>> Following Stephen's advice here:
>>> http://kerneltrap.org/mailarchive/linux-netdev/2008/9/24/3398834 I checked the macb.c code
>>> and noticed they do not call netif_carrier_off() neither before register_netdev() nor in
>>> dev_open().
>
>> It should be called after register_netdev() and before the driver's
>> ndo_open implementation returns.
After having read several drivers, it seems that some are calling
netif_carrier_off() *before* register_netdev() and some *after*... What
is the proper way?
> I'm guessing this allows linkwatch to do netif_carrier_on() some time after the dev_open()?
>
> Besides not calling netif_carrier_off() in dev_open(), the Cadence/MACB driver calls
> netif_carrier_off() in dev_close(). Is this correct?
>
>
> How should I handle carrier state for a virtual device? The device should have "carrier"
> as long as at least one of the underlying physical interfaces is operational (which I
> guess means operational state UP). Would it be correct to watch NETDEV_CHANGE and DOWN/UP
> events of the slaves and call netif_carrier_on()/off() on the virtual device depending on
> the slaves' states?
>>
>>> I added the call before register_netdev(), which fixed the problem. However, if I then
>>> enable IPv6:
>>>
>>> # ip link set eth0 up
>>> ADDRCONF(NETDEV_UP): eth0: link is not ready
>>> eth0: link up (100/Full)
>>> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>
>> This looks normal.
>
> Good, that narrows it down a bit.
>
>>
>>> Any idea what is happening / what I'm doing wrong? (This is not just cosmetic; is some
>>> situations this seems to kill the interface - e.g. ping does not work, down/up does not
>>> help...) Things work fine without IPv6 configured.
>>
>> Perhaps some packets sent automatically by IPv6 are triggering a driver
>> bug? Or there is a bug in multicast support, which IPv6 always uses.
Sorry, I have no clue on this topic. But I am eager to know if you find
something. I can queue your patch for netif_carrier_off() at least...
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: AF_BUS socket address family
From: Chris Friesen @ 2012-07-03 16:52 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: David Miller, vincent.sanders, netdev, linux-kernel
In-Reply-To: <4FF1BBD5.8080804@collabora.co.uk>
On 07/02/2012 09:18 AM, Javier Martinez Canillas wrote:
> We tried different approaches before developing the AF_BUS socket family and one
> of them was extending AF_UNIX to support multicast. We posted our patches [1]
> and the feedback was that the AF_UNIX code was already a complex and difficult
> code to maintain. So, we decided to implement a new family (AF_BUS) that is
> orthogonal to the rest of the networking stack and no added complexity nor
> performance penalty would pay a user not using our IPC solution.
That's what I ended up doing as well. In our case it's basically a
stripped-down AF_UNIX with only datagram support, no security, no fd
passing, etc., but with with the addition of multicast and wildcard (for
debugging).
> Looking at netdev archives I saw that you both raised the question about
> multicast on unix sockets and post an implementation on early 2003. So if I
> understand correctly you are maintaining an out-of-tree solution for around 9
> years now.
That's correct.
> It would be a great help if you can join the discussion and explain the
> arguments of your company (and the others companies you were talking about) in
> favor of a simpler multicast socket family.
>
> The fact that your company spent lots of engineering resources to maintain an
> out-of-tree patch-set for 9 years should raise some eyebrows and convince more
> than one people that a simpler local multicast solution is needed on the Linux
> kernel (which was one of the reasons why Google also developed Binder I guess).
To be fair, since it was implemented as a separate protocol family the
maintenance burden actually hasn't been large--it's been fairly simple
to port between versions. Also, we do embedded telecom stuff and don't
jump kernel versions all that often. (It's a big headache, requires
coordinating between multiple vendors, etc.)
In our case we typically send small (100-200 byte) messages to a
smallish (1-10) number of listeners, though there are exceptions of
course. Back before I started the original implementation used a
userspace daemon, but it had a number of issues. Originally I was
focussed on the performance gains but I must admit that since then other
factors have made that less of an issue.
Among other things, this messaging is used on some systems to configure
the IP addressing for the system, so it does simplify things to not use
an IP-based protocol for this purpose.
Also, back when I did my original implementation IP multicast wasn't
supported on the loopback device--David, has that changed since then?
If it has, then we probably could figure out a way to make it work using
IP multicast, but I don't know that it would be worth the effort given
the minimal ongoing maintenance costs for our patch.
Chris
^ permalink raw reply
* Re: AF_BUS socket address family
From: Chris Friesen @ 2012-07-03 17:18 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: David Miller, vincent.sanders, netdev, linux-kernel
In-Reply-To: <4FF32352.5040800@genband.com>
On 07/03/2012 10:52 AM, Chris Friesen wrote:
> To be fair, since it was implemented as a separate protocol family the
> maintenance burden actually hasn't been large--it's been fairly simple
> to port between versions. Also, we do embedded telecom stuff and don't
> jump kernel versions all that often. (It's a big headache, requires
> coordinating between multiple vendors, etc.)
>
> In our case we typically send small (100-200 byte) messages to a
> smallish (1-10) number of listeners, though there are exceptions of
> course. Back before I started the original implementation used a
> userspace daemon, but it had a number of issues. Originally I was
> focussed on the performance gains but I must admit that since then other
> factors have made that less of an issue.
I should point out that some of the other factors that have been
discussed for AF_BUS also hold true for our implementation:
--strict ordering
--reliable (in our case, if the sender has space in the tx buffer then
messages get to all recipients with buffer space, there are kernel logs
if recipients don't have space)
Also, the fact that it's in the kernel rather than a userspace daemon
reduces priority inversion type issues. Presumably this would apply to
an IP-multicast based solution as well.
One problem that I ran into back when I was experimenting with this
stuff was trying to isolate host-local IP multicast from the rest of the
network. It would be suboptimal to need to set up filtering and such
before being able to use the communication protocol.
Chris
^ permalink raw reply
* Re: [PATCH v6] sctp: be more restrictive in transport selection on bundled sacks
From: Jan Ceuleers @ 2012-07-03 18:45 UTC (permalink / raw)
To: Neil Horman; +Cc: David Miller, netdev, vyasevich, linux-sctp
In-Reply-To: <20120702122531.GA29681@hmsreliant.think-freely.org>
On 07/02/2012 02:25 PM, Neil Horman wrote:
...
> How does this language sound to you?
...
> +tree maintanier may reapply the subsystem maintainers Acked-by: to the new
s/maintanier/maintainer/
HTH, Jan
^ permalink raw reply
* RE: [PATCH net 1/7] qlge: Fixed packet transmit errors due to potential driver errors.
From: Jitendra Kalsaria @ 2012-07-03 19:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ron Mercer, Dept-NX Linux NIC Driver
In-Reply-To: <20120702.184134.1131493483786674336.davem@davemloft.net>
-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Monday, July 02, 2012 6:42 PM
>To: Jitendra Kalsaria
>Cc: netdev; Ron Mercer; Dept-NX Linux NIC Driver
>Subject: Re: [PATCH net 1/7] qlge: Fixed packet transmit errors due to potential driver errors.
>
>From: David Miller <davem@davemloft.net>
>Date: Mon, 02 Jul 2012 18:38:26 -0700 (PDT)
>
>> From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>> Date: Mon, 2 Jul 2012 18:30:47 -0700
>>
>>> As per your comments, TX ring full is not expected behavior? All I
>>> can think of increasing the TX queue to 1024 and clean-up in timer
>>> instead of interrupt?
>>
>> Your transmit function should never be invoked when the queue is
>> full, logic elsewhere in your driver should have stopped the queue
>> therefore preventing further invocations of your transmit function
>> until you wake the queue when space is liberated in the TX ring.
>
>BTW, did it even occur to you that there is a kernel log message here
>in this code path for a reason?
>
>That log message is there because this event is unexpected and a
>driver error.
I think my patch description might have been misleading. We are not fixing a logical problem but rather a statistics reporting problem. Our transmit function is not getting called when queue is full but when we stop the queue it increment tx_error statistic and one of our customers is running a test that deliberately floods the queue causing it to periodically be stopped. The customer has not reported logical problem with the test were driver perform very well but they merely pointed out that we were incorrectly reporting the queue full condition as a tx_error.
This patch was intended to remove the line that increments the tx_error statistic when the queue is correctly stopped.
^ permalink raw reply
* Greetings to you!
From: Stacy Anna Scott @ 2012-07-03 19:49 UTC (permalink / raw)
My name is Ms Stacy Ann Scott from London, I would like to have an important discussion with you. It’s private, for more details. please kindly Contact me on my email: stacyannascott@yahoo.com
Thanks,
Yours truly,
Ms Stacy A Scott.
^ permalink raw reply
* RE: [PATCH net 1/7] qlge: Fixed packet transmit errors due to potential driver errors.
From: Eric Dumazet @ 2012-07-03 20:27 UTC (permalink / raw)
To: Jitendra Kalsaria
Cc: David Miller, netdev, Ron Mercer, Dept-NX Linux NIC Driver
In-Reply-To: <5E4F49720D0BAD499EE1F01232234BA877435B2797@AVEXMB1.qlogic.org>
On Tue, 2012-07-03 at 12:38 -0700, Jitendra Kalsaria wrote:
> I think my patch description might have been misleading. We are not
> fixing a logical problem but rather a statistics reporting problem.
> Our transmit function is not getting called when queue is full but
> when we stop the queue it increment tx_error statistic and one of our
> customers is running a test that deliberately floods the queue causing
> it to periodically be stopped. The customer has not reported logical
> problem with the test were driver perform very well but they merely
> pointed out that we were incorrectly reporting the queue full
> condition as a tx_error.
>
> This patch was intended to remove the line that increments the
> tx_error statistic when the queue is correctly stopped.
I believe everybody kindly ask you to fix the driver logic instead
of trying to hide to your customers the problems.
In fact, you could just BUG() at this point, and maybe David will accept
such a patch.
testing atomic_read(&tx_ring->tx_count) at the beginning of qlge_send()
is too late. NETDEV_TX_BUSY is deprecated.
Well behaving drivers should perform the test at the end of their
ndo_start_xmit() and stop the queue so that next packet wont come at
all.
^ permalink raw reply
* Re: [PATCH] netem: fix rate extension and drop accounting
From: Hagen Paul Pfeifer @ 2012-07-03 22:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Yuchung Cheng, Andreas Terzis, Mark Gordon
In-Reply-To: <1341309257.2583.153.camel@edumazet-glaptop>
* Eric Dumazet | 2012-07-03 11:54:17 [+0200]:
>> commit 7bc0f28c7a0c (netem: rate extension) did wrong maths when packet
>> is enqueued while queue is not empty.
>>
>> Result is unexpected cumulative delays
>>
>> # tc qd add dev eth0 root est 1sec 4sec netem delay 200ms rate 100kbit
>> # ping -i 0.1 172.30.42.18
>> PING 172.30.42.18 (172.30.42.18) 56(84) bytes of data.
>> 64 bytes from 172.30.42.18: icmp_req=1 ttl=64 time=208 ms
>> 64 bytes from 172.30.42.18: icmp_req=2 ttl=64 time=424 ms
>> 64 bytes from 172.30.42.18: icmp_req=3 ttl=64 time=838 ms
>> 64 bytes from 172.30.42.18: icmp_req=4 ttl=64 time=1142 ms
>> 64 bytes from 172.30.42.18: icmp_req=5 ttl=64 time=1335 ms
>> 64 bytes from 172.30.42.18: icmp_req=6 ttl=64 time=1949 ms
>> 64 bytes from 172.30.42.18: icmp_req=7 ttl=64 time=2450 ms
>> 64 bytes from 172.30.42.18: icmp_req=8 ttl=64 time=2840 ms
>> 64 bytes from 172.30.42.18: icmp_req=9 ttl=64 time=3121 ms
>> 64 bytes from 172.30.42.18: icmp_req=10 ttl=64 time=3291 ms
>> 64 bytes from 172.30.42.18: icmp_req=11 ttl=64 time=3784 ms
Strange, we test the patch in detail. I will take a look ...
^ permalink raw reply
* Re: [PATCH 12/19] neigh: Convert over to dst_neigh_lookup_skb().
From: Ben Hutchings @ 2012-07-03 22:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120703.024644.638173463391088464.davem@davemloft.net>
On Tue, 2012-07-03 at 02:46 -0700, David Miller wrote:
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> net/core/neighbour.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index a793af9..eb3efdc 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -1202,9 +1202,15 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
>
> rcu_read_lock();
> /* On shaper/eql skb->dst->neighbour != neigh :( */
It might be time to delete that comment too.
Ben.
> - if (dst && (n2 = dst_get_neighbour_noref(dst)) != NULL)
> - n1 = n2;
> + n2 = NULL;
> + if (dst) {
> + n2 = dst_neigh_lookup_skb(dst, skb);
> + if (n2)
> + n1 = n2;
> + }
> n1->output(n1, skb);
> + if (n2)
> + neigh_release(n2);
> rcu_read_unlock();
>
> write_lock_bh(&neigh->lock);
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [RFC PATCH 00/10] Make XPS usable within ixgbe
From: Tom Herbert @ 2012-07-03 22:30 UTC (permalink / raw)
To: Alexander Duyck
Cc: netdev, davem, jeffrey.t.kirsher, edumazet, bhutchings,
alexander.duyck
In-Reply-To: <20120630000652.29939.11108.stgit@gitlad.jf.intel.com>
Hi Alexander,
Thanks for this work!
Some general comments:
1) skb_tx_hash is called from a handful of drivers (bnx2x, ixgbe,
mlx4, and bonding). Would it make sent to call xps_get_cpu from that
function (unfortunately the use of ndo_select_queue is likely
bypassing xps unnecessarily in these drivers).
2) Instead of (or maybe in addition to) allowing driver to program xps
maps, we could parameterize get_xps_cpu to optionally include a bit
map of acceptable queues. This would be useful to define a
hierarchical queue selection (like first choose a set for QoS, then
amongst those chose one base on xps).
Tom
On Fri, Jun 29, 2012 at 5:16 PM, Alexander Duyck
<alexander.h.duyck@intel.com> wrote:
> The following patch series makes it so that the ixgbe driver can support
> ATR even when the number of queues is less than the number of CPUs. To do
> this I have updated the kernel to support letting drivers set their own XPS
> configuration. To do this it was necessary to move the code out of the
> sysfs specific code and into the dev specific regions.
>
> I am still working out a few issues such as the fact that with routing I
> only ever seem to be able to get the first queue that is mapped to the CPU
> when XPS is enabled.
>
> Also I am looking for input on if it is acceptable to only let the
> set_channels/get_channels calls report/set the number of queues per traffic
> class as I implemented the code this way to avoid any significant conflicts
> between the DCB traffic classes code and these functions.
>
> ---
>
> Alexander Duyck (10):
> ixgbe: Add support for set_channels ethtool operation
> ixgbe: Add support for displaying the number of Tx/Rx channels
> ixgbe: Update ixgbe driver to use __dev_pick_tx in ixgbe_select_queue
> ixgbe: Add function for setting XPS queue mapping
> ixgbe: Define FCoE and Flow director limits much sooner to allow for changes
> net: Add support for XPS without SYSFS being defined
> net: Rewrite netif_set_xps_queues to address several issues
> net: Rewrite netif_reset_xps_queue to allow for better code reuse
> net: Add functions netif_reset_xps_queue and netif_set_xps_queue
> net: Split core bits of dev_pick_tx into __dev_pick_tx
>
>
> drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 112 +++++++++
> drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 10 -
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 48 +++-
> include/linux/netdevice.h | 15 +
> net/Kconfig | 2
> net/core/dev.c | 283 ++++++++++++++++++++--
> net/core/net-sysfs.c | 160 ------------
> 7 files changed, 428 insertions(+), 202 deletions(-)
>
> --
> Thanks,
>
> Alex
^ 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