* [RFC v2 0/2] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Arvid Brodin @ 2012-07-03 23:58 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: Stephen Hemminger, Alexey Kuznetsov, Javier Boticario,
Bruno Ferreira
Hi,
This is v2 of this RFC. Background information about this patch and HSR can be found in
the v1 submit: http://www.spinics.net/lists/netdev/msg192817.html.
This patch is now quite useable.
Known major functional problems:
* Sometimes, when used with slaves that are already up and using IPv6, no packets seem
to get through. (Possibly a bug in the driver for my slave interfaces - not sure yet.)
Other problems:
* There are a few FIXMEs that might need attention - except "reset status of slaves",
these are things I could use some help with.
* The kernel patch is against linux-next-120330 (so not quite up to date).
* The iproute patch is against iproute-2.6.35.
* The code needs cleanup, there are some commented debug printouts and such.
Major changes to v1:
* Added iproute patch.
* Fixed lockdep problem.
* Moved to Generic Netlink for HSR-specific userspace comms.
* Added userspace Generic Netlink example.
* Added HSR address substitution (so slaves kan keep their MAC addresses).
Part 1/2 contains the kernel patch (including the userspace example).
Part 2/2 contains the iproute patch (applies to iproute-2.6.35).
(I'm going on holiday on thursday so don't feel hurt if you write me and don't get a
reply. I'll check your messages when I get back early august though!)
--
Arvid Brodin | Consultant (Linux)
XDIN AB | Jan Stenbecks Torg 17 | SE-164 40 Kista | Sweden | xdin.com
^ permalink raw reply
* Re: [PATCH v6] sctp: be more restrictive in transport selection on bundled sacks
From: Neil Horman @ 2012-07-03 23:42 UTC (permalink / raw)
To: Jan Ceuleers; +Cc: David Miller, netdev, vyasevich, linux-sctp
In-Reply-To: <4FF33DBE.7060103@computer.org>
On Tue, Jul 03, 2012 at 08:45:18PM +0200, Jan Ceuleers wrote:
> 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
Thanks Jan, I've fixed it in my local tree, it'll get rolled in the next
version.
Neil
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] netdev: driver: ethernet: add sysfs interface for ti cpsw
From: John Fastabend @ 2012-07-03 23:38 UTC (permalink / raw)
To: s-paulraj; +Cc: David Miller, cyril, mugunthanvnm, netdev
In-Reply-To: <20120703.161623.1843927245895613219.davem@davemloft.net>
On 7/3/2012 4:16 PM, David Miller wrote:
> From: <s-paulraj@ti.com>
> Date: Tue, 3 Jul 2012 15:51:26 -0400
>
>> From: Sandeep Paulraj <s-paulraj@ti.com>
>>
>> This patch adds sysfs entries for address lookup engine entries and
>> control for the ALE(address lookup engine) found in TI SOC's.
>>
>>
>> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
>
> You may not create private, driver specific, unique interfaces to
> configure your hardware.
>
> You must use existing facilities such as ethtool to add such things.
> If the existing facilities are insufficient, you must extend them to
> meet your (and potentially other's) needs.
> --
I can't seem to dig up the original email perhaps my server is slow
today but did you consider using these hooks ndo_fdb_add(),
ndo_fdb_del(), and ndo_fdb_dump() added recently.
These are for adding/deleting and dumping the address forwarding
databases. Failing that would something like this RFC with another
attribute work,
http://comments.gmane.org/gmane.linux.network/232104
Thanks,
John
^ permalink raw reply
* Re: [PATCH 12/19] neigh: Convert over to dst_neigh_lookup_skb().
From: David Miller @ 2012-07-03 23:18 UTC (permalink / raw)
To: bhutchings; +Cc: netdev
In-Reply-To: <1341353309.2839.19.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 3 Jul 2012 23:08:29 +0100
> 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.
It's still accurate, so it needs to be adjusted rather then removed.
sch_teql creates this situation as well.
What this code is effectively doing is reinjecting the packet back to
the top-most neigh, and it will filter back down to the thing that
uses a different neigh for packet output.
^ permalink raw reply
* [PATCH] net/fsl_pq_mdio: use spin_event_timeout() to poll the indicator register
From: Timur Tabi @ 2012-07-03 23:16 UTC (permalink / raw)
To: Andy Fleming, davem, netdev
Macro spin_event_timeout() was designed for simple polling of hardware
registers with a timeout, so use it when we poll the MIIMIND register.
This allows us to return an error code instead of polling indefinitely.
Note that PHY_INIT_TIMEOUT is a count of loop iterations, so we can't use
it for spin_event_timeout(), which asks for microseconds.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 25 +++++++++++++++----------
1 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
index 9eb8159..ab0fabd 100644
--- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
+++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
@@ -64,6 +64,8 @@ struct fsl_pq_mdio_priv {
int fsl_pq_local_mdio_write(struct fsl_pq_mdio __iomem *regs, int mii_id,
int regnum, u16 value)
{
+ u32 status;
+
/* Set the PHY address and the register address we want to write */
out_be32(®s->miimadd, (mii_id << 8) | regnum);
@@ -71,10 +73,10 @@ int fsl_pq_local_mdio_write(struct fsl_pq_mdio __iomem *regs, int mii_id,
out_be32(®s->miimcon, value);
/* Wait for the transaction to finish */
- while (in_be32(®s->miimind) & MIIMIND_BUSY)
- cpu_relax();
+ status = spin_event_timeout(!(in_be32(®s->miimind) & MIIMIND_BUSY),
+ 1000, 0);
- return 0;
+ return status ? 0 : -ETIMEDOUT;
}
/*
@@ -91,6 +93,7 @@ int fsl_pq_local_mdio_read(struct fsl_pq_mdio __iomem *regs,
int mii_id, int regnum)
{
u16 value;
+ u32 status;
/* Set the PHY address and the register address we want to read */
out_be32(®s->miimadd, (mii_id << 8) | regnum);
@@ -99,9 +102,11 @@ int fsl_pq_local_mdio_read(struct fsl_pq_mdio __iomem *regs,
out_be32(®s->miimcom, 0);
out_be32(®s->miimcom, MII_READ_COMMAND);
- /* Wait for the transaction to finish */
- while (in_be32(®s->miimind) & (MIIMIND_NOTVALID | MIIMIND_BUSY))
- cpu_relax();
+ /* Wait for the transaction to finish, normally less than 100us */
+ status = spin_event_timeout(!(in_be32(®s->miimind) &
+ (MIIMIND_NOTVALID | MIIMIND_BUSY)), 1000, 0);
+ if (!status)
+ return -ETIMEDOUT;
/* Grab the value of the register from miimstat */
value = in_be32(®s->miimstat);
@@ -144,7 +149,7 @@ int fsl_pq_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
static int fsl_pq_mdio_reset(struct mii_bus *bus)
{
struct fsl_pq_mdio __iomem *regs = fsl_pq_mdio_get_regs(bus);
- int timeout = PHY_INIT_TIMEOUT;
+ u32 status;
mutex_lock(&bus->mdio_lock);
@@ -155,12 +160,12 @@ static int fsl_pq_mdio_reset(struct mii_bus *bus)
out_be32(®s->miimcfg, MIIMCFG_INIT_VALUE);
/* Wait until the bus is free */
- while ((in_be32(®s->miimind) & MIIMIND_BUSY) && timeout--)
- cpu_relax();
+ status = spin_event_timeout(!(in_be32(®s->miimind) & MIIMIND_BUSY),
+ 1000, 0);
mutex_unlock(&bus->mdio_lock);
- if (timeout < 0) {
+ if (!status) {
printk(KERN_ERR "%s: The MII Bus is stuck!\n",
bus->name);
return -EBUSY;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] netdev: driver: ethernet: add sysfs interface for ti cpsw
From: David Miller @ 2012-07-03 23:16 UTC (permalink / raw)
To: s-paulraj; +Cc: cyril, mugunthanvnm, netdev
In-Reply-To: <1341345086-25093-1-git-send-email-s-paulraj@ti.com>
From: <s-paulraj@ti.com>
Date: Tue, 3 Jul 2012 15:51:26 -0400
> From: Sandeep Paulraj <s-paulraj@ti.com>
>
> This patch adds sysfs entries for address lookup engine entries and
> control for the ALE(address lookup engine) found in TI SOC's.
>
>
> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
You may not create private, driver specific, unique interfaces to
configure your hardware.
You must use existing facilities such as ethtool to add such things.
If the existing facilities are insufficient, you must extend them to
meet your (and potentially other's) needs.
^ permalink raw reply
* Re: [PATCH net 1/7] qlge: Fixed packet transmit errors due to potential driver errors.
From: David Miller @ 2012-07-03 23:14 UTC (permalink / raw)
To: jitendra.kalsaria; +Cc: netdev, ron.mercer, Dept_NX_Linux_NIC_Driver
In-Reply-To: <5E4F49720D0BAD499EE1F01232234BA877435B2797@AVEXMB1.qlogic.org>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Date: Tue, 3 Jul 2012 12:38:04 -0700
> This patch was intended to remove the line that increments the
> tx_error statistic when the queue is correctly stopped.
It isn't correctly stopped, for the millionth time this condition is a
BUG, there is a kernel log message there because it is a BUG, are you
blind?
if (unlikely(atomic_read(&tx_ring->tx_count) < 2)) {
netif_info(qdev, tx_queued, qdev->ndev,
"%s: shutting down tx queue %d du to lack of resources.\n",
__func__, tx_ring_idx);
netif_stop_subqueue(ndev, tx_ring->wq_id);
atomic_inc(&tx_ring->queue_stopped);
tx_ring->tx_errors++;
return NETDEV_TX_BUSY;
}
THIS CODE BLOCK SHOULD NEVER EXECUTE. It's a driver bug, it should
never happen.
Even if the driver recovers correctly, it's still an error condition.
It's a bug, and bumping the statistic is not wrong at all. You should
find out why this happens, because it's a bug, and it should be fixed.
^ permalink raw reply
* Re: [RFC PATCH 00/10] Make XPS usable within ixgbe
From: John Fastabend @ 2012-07-03 22:41 UTC (permalink / raw)
To: Tom Herbert, Alexander Duyck
Cc: netdev, davem, jeffrey.t.kirsher, edumazet, bhutchings,
alexander.duyck
In-Reply-To: <CA+mtBx-ZGFUT6JcxiLcTOMteN1-DS5_eoAC5CgU7UEFup1FaqQ@mail.gmail.com>
On 7/3/2012 3:30 PM, Tom Herbert wrote:
> 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).
I suspect we can get rid of the select_queue cases for at least
bnx2x, ixgbe, and mlx4. We might need to be a bit clever to resolve
the mlx4 case but should be doable.
Anyways I would like to see these cases refactored away.
> 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).
>
Agreed.
We likely need something like (2) to get this to work with mqprio and
other QOS schemes in use.
.John
^ permalink raw reply
* Re: [PATCH net 1/7] qlge: Fixed packet transmit errors due to potential driver errors.
From: Francois Romieu @ 2012-07-03 22:22 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jitendra Kalsaria, David Miller, netdev, Ron Mercer,
Dept-NX Linux NIC Driver
In-Reply-To: <1341347235.2583.796.camel@edumazet-glaptop>
Eric Dumazet <eric.dumazet@gmail.com> :
> 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.
:o/
Jitendra was speaking about qlge_ethtool_ops.self_test(). It will need
fixing as well.
> In fact, you could just BUG() at this point, and maybe David will accept
> such a patch.
Mildly. It would turn qlge_ethtool_ops.self_test() into a system killer.
[...]
> testing atomic_read(&tx_ring->tx_count) at the beginning of qlge_send()
> is too late. NETDEV_TX_BUSY is deprecated.
Yes.
Returning NETDEV_TX_BUSY when dma mapping fails in ql_map_send isn't nice
either.
--
Ueimor
^ permalink raw reply
* RE: [PATCH net 1/7] qlge: Fixed packet transmit errors due to potential driver errors.
From: Jitendra Kalsaria @ 2012-07-03 22:33 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Ron Mercer, Dept-NX Linux NIC Driver,
krkumar2@in.ibm.com
In-Reply-To: <1341347235.2583.796.camel@edumazet-glaptop>
-----Original Message-----
>From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>Sent: Tuesday, July 03, 2012 1:27 PM
>To: Jitendra Kalsaria
>Cc: David Miller; netdev; Ron Mercer; Dept-NX Linux NIC Driver
>Subject: RE: [PATCH net 1/7] qlge: Fixed packet transmit errors due to potential driver errors.
>
>On Tue, 2012-07-03 at 12:38 -0700, Jitendra Kalsaria wrote:
>
>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.
Thanks everyone and will definitely change the logic.
^ 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
* 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: [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 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
* 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: 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
* 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: 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: 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: "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: "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: 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: [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: [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: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
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