* Re: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Daniel Mack @ 2012-08-02 20:17 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: netdev, mugunthanvnm, paul, devicetree-discuss, koen,
linux-arm-kernel
In-Reply-To: <20120802195308.GZ6802@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
On 02.08.2012 21:53, Russell King - ARM Linux wrote:
> On Thu, Aug 02, 2012 at 09:43:35PM +0200, Daniel Mack wrote:
>> Make the driver control the device clocks. Appearantly, the Davinci
>> platform probes this driver with the clock all powered up, but on OMAP,
>> this isn't the case.
>
> Hmm, this looks like it could do with improvement, especially as we're
> moving everything over to a common clk API.
>
> 1. This driver could do with clk_prepare()/clk_unprepare() calls.
Ok, done.
> 2. This driver should not be making the assumption that NULL means
> it can avoid clk_* calls. It should instead be using
> if (!IS_ERR(clk))
Well spotted. Amended patch below.
Thanks,
Daniel
[-- Attachment #2: 0001-net-davinci_mdio-prepare-and-unprepare-clocks.patch --]
[-- Type: text/x-patch, Size: 2045 bytes --]
>From 57670e52d19218f897d835d25223bf4b4932252f Mon Sep 17 00:00:00 2001
From: Daniel Mack <zonque@gmail.com>
Date: Thu, 2 Aug 2012 21:24:36 +0200
Subject: [PATCH] net: davinci_mdio: prepare and unprepare clocks
Make the driver control the device clocks. Appearantly, the Davinci
platform probes this driver with the clock all powered up, but on OMAP,
this isn't the case.
While at it, also check for IS_ERR(data->clk) in the bail_out: label of
.probe().
Signed-off-by: Daniel Mack <zonque@gmail.com>
---
drivers/net/ethernet/ti/davinci_mdio.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index cd7ee20..462f81d 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -332,6 +332,8 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
goto bail_out;
}
+ clk_prepare(data->clk);
+
dev_set_drvdata(dev, data);
data->dev = dev;
spin_lock_init(&data->lock);
@@ -379,8 +381,11 @@ bail_out:
if (data->bus)
mdiobus_free(data->bus);
- if (data->clk)
+ if (data->clk && !IS_ERR(data->clk)) {
+ clk_unprepare(data->clk);
clk_put(data->clk);
+ }
+
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
@@ -397,8 +402,11 @@ static int __devexit davinci_mdio_remove(struct platform_device *pdev)
if (data->bus)
mdiobus_free(data->bus);
- if (data->clk)
+ if (data->clk) {
+ clk_unprepare(data->clk);
clk_put(data->clk);
+ }
+
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
@@ -427,6 +435,8 @@ static int davinci_mdio_suspend(struct device *dev)
data->suspended = true;
spin_unlock(&data->lock);
+ clk_unprepare(data->clk);
+
return 0;
}
@@ -435,6 +445,8 @@ static int davinci_mdio_resume(struct device *dev)
struct davinci_mdio_data *data = dev_get_drvdata(dev);
u32 ctrl;
+ clk_prepare(data->clk);
+
spin_lock(&data->lock);
pm_runtime_put_sync(data->dev);
--
1.7.11.2
^ permalink raw reply related
* Re: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Paul Walmsley @ 2012-08-02 20:20 UTC (permalink / raw)
To: Daniel Mack
Cc: netdev, devicetree-discuss, koen, mugunthanvnm, linux-arm-kernel
In-Reply-To: <1343936616-29318-1-git-send-email-zonque@gmail.com>
Hi
On Thu, 2 Aug 2012, Daniel Mack wrote:
> Make the driver control the device clocks. Appearantly, the Davinci
> platform probes this driver with the clock all powered up, but on OMAP,
> this isn't the case.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> drivers/net/ethernet/ti/davinci_mdio.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> index cd7ee20..b4b6015 100644
> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> @@ -332,6 +332,8 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
> goto bail_out;
> }
>
> + clk_enable(data->clk);
> +
This doesn't look right. This clock should be enabled by the
pm_runtime_get_sync() call just above this. It shouldn't be necessary
to enable it again unless something isn't right with the integration
data. Likewise the pm_runtime_put_sync() calls should be superfluous.
What hwmod data/device tree file are you using with this?
- Paul
^ permalink raw reply
* Re: [PATCH] igb: reduce Rx header size
From: Jeff Kirsher @ 2012-08-02 20:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alexander Duyck, netdev
In-Reply-To: <1343920538.9299.200.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
On Thu, 2012-08-02 at 17:15 +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Reduce skb truesize by 256 bytes.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
> Tested on my machine without any problem
>
> drivers/net/ethernet/intel/igb/igb.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks Eric, I have added it to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Daniel Mack @ 2012-08-02 20:28 UTC (permalink / raw)
To: Paul Walmsley
Cc: netdev, devicetree-discuss, koen, mugunthanvnm, linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1208021416550.18867@utopia.booyaka.com>
On 02.08.2012 22:20, Paul Walmsley wrote:
> Hi
>
> On Thu, 2 Aug 2012, Daniel Mack wrote:
>
>> Make the driver control the device clocks. Appearantly, the Davinci
>> platform probes this driver with the clock all powered up, but on OMAP,
>> this isn't the case.
>>
>> Signed-off-by: Daniel Mack <zonque@gmail.com>
>
>> ---
>> drivers/net/ethernet/ti/davinci_mdio.c | 16 ++++++++++++++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
>> index cd7ee20..b4b6015 100644
>> --- a/drivers/net/ethernet/ti/davinci_mdio.c
>> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
>> @@ -332,6 +332,8 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
>> goto bail_out;
>> }
>>
>> + clk_enable(data->clk);
>> +
>
> This doesn't look right. This clock should be enabled by the
> pm_runtime_get_sync() call just above this. It shouldn't be necessary
> to enable it again unless something isn't right with the integration
> data. Likewise the pm_runtime_put_sync() calls should be superfluous.
Aah, thanks for the heads-up. To explain, I first worked with a dirty
hack to alias the clock, and I definitely needed these extra calls then.
> What hwmod data/device tree file are you using with this?
Later, I added the hwmod to move away from these hacks, and indeed, that
lets the pm runtime code handle the clock enabling. With that in place,
the patch we're talking about here is in fact unnecessary.
The second one though (the one that adds DT bindings) should go in.
I will send a separate one later that fixes the IS_ERR(data->clk) error
that Russell spotted. But that's now unrelated.
Thanks for the review,
Daniel
^ permalink raw reply
* Re: [PATCH net-next] igb: use build_skb()
From: Jeff Kirsher @ 2012-08-02 20:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alexander Duyck, netdev
In-Reply-To: <1343922692.9299.231.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
On Thu, 2012-08-02 at 17:51 +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> By using netdev_alloc_frag() & build_skb() instead of legacy
> netdev_alloc_skb_ip_align() calls, we reduce number of cache misses in
> RX path and size of working set.
>
> For a given rx workload, number of 'inuse' sk_buff can be reduced to a
> very minimum, especially when packets are dropped by our stack.
>
> (Before this patch, default sk_buff allocation was 2048 sk_buffs in rx
> ring buffer)
>
> They are initialized right before being delivered to stack, so can
> stay
> hot in cpu caches.
>
> Ethernet header prefetching is more effective (old prefetch of
> skb->data
> paid a stall to access skb->data pointer)
>
> I have 15% performance increase in a RX stress test, removing SLUB
> slow
> path in the profiles.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb.h | 8 ++
> drivers/net/ethernet/intel/igb/igb_ethtool.c | 14 ++--
> drivers/net/ethernet/intel/igb/igb_main.c | 56 ++++++++++-------
> 3 files changed, 49 insertions(+), 29 deletions(-)
Thanks Eric, I have added this as well to my queue.
NOTE- you had some trailing whitespace errors in igb.h which I cleaned
up before adding to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: discussion questions: SR-IOV, virtualization, and bonding
From: Jay Vosburgh @ 2012-08-02 20:30 UTC (permalink / raw)
To: Chris Friesen; +Cc: e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <501AD33E.5090308@genband.com>
Chris Friesen <chris.friesen@genband.com> wrote:
>Hi all,
>
>I wanted to just highlight some issues that we're seeing and see what
>others are doing in this area.
>
>Our configuration is that we have a host with SR-IOV-capable NICs with
>bonding enabled on the PF. Depending on the exact system it could be
>active/standby or some form of active/active.
>
>In the guests we generally have several VFs (corresponding to several
>PFs) and we want to bond them for reliability.
>
>We're seeing a number of issues:
>
>1) If the guests use arp monitoring then broadcast arp packets from the
>guests are visible on the other guests and on the host, and can cause
>them to think the link is good even if we aren't receiving arp packets
>from the external network. (I'm assuming carrier is up.)
>
>2) If both the host and guest use active/backup but pick different
>devices as the active, there is no traffic between host/guest over the
>bond link. Packets are sent out the active and looped back internally
>to arrive on the inactive, then skb_bond_should_drop() suppresses them.
Just to be sure that I'm following this correctly, you're
setting up active-backup bonds on the guest and the host. The guest
sets its active slave to be a VF from "SR-IOV Device A," but the host
sets its active slave to a PF from "SR-IOV Device B." Traffic from the
guest to the host then arrives at the host's inactive slave (it's PF for
"SR-IOV Device A") and is then dropped.
Correct?
>3) For active/standby the default is to set the standby to the MAC
>address of the bond. If the host has already set the MAC address (using
>some algorithm to ensure uniqueness within the local network) then the
>guest is not allowed to change it.
>
>
>So far the solutions to 1 seem to be either using arp validation (which
>currently doesn't exist for loadbalancing modes) or else have the
>underlying ethernet driver distinguish between packets coming from the
>wire vs being looped back internally and have the bonding driver only
>set last_rx for external packets.
As discussed previously, e.g.,:
http://marc.info/?l=linux-netdev&m=134316327912154&w=2
implementing arp_validate for load balance modes is tricky at
best, regardless of SR-IOV issues.
This is really a variation on the situation that led to the
arp_validate functionality in the first place (that multiple instances
of ARP monitor on a subnet can fool one another), except that the switch
here is within the SR-IOV device and the various hosts are guests.
The best long term solution is to have a user space API that
provides link state input to bonding on a per-slave basis, and then some
user space entity can perform whatever link monitoring method is
appropriate (e.g., LLDP) and pass the results to bonding.
>For issue 2, it would seem beneficial for the host to be able to ensure
>that the guest uses the same link as the active. I don't see a tidy
>solution here. One somewhat messy possibility here is to have bonding
>send a message to the standby PF which then tells all its VFs to fake
>loss of carrier.
There is no tidy solution here that I'm aware of; this has been
a long standing concern in bladecenter type of network environments,
wherein all blade "eth0" interfaces connect to one chassis switch, and
all blade "eth1" interfaces connect to a different chassis switch. If
those switches are not connected, then there may not be a path from
blade A:eth0 to blade B:eth1. There is no simple mechanism to force a
gang failover across multiple hosts.
That said, I've seen a slight rub on this using virtualized
network devices (pseries ehea, which is similar in principle to SR-IOV,
although implemented differently). In that case, the single ehea card
provides all "eth0" devices for all lpars (logical partitions,
"guests"). A separate card (or individual per-lpar cards) provides the
"eth1" devices.
In this configuration, the bonding primary option is used to
make eth0 the primary, and thus all lpars use eth0 preferentially, and
there is no connectivity issue. If the ehea card itself fails, all of
the bonds will fail over simultaneously to the backup devices, and
again, there is no connectivity issue. This works because the ehea is a
single point of failure for all of the partitions.
Note that the ehea can propagate link failure of its external
port (the one that connects to a "real" switch) to its internal ports
(what the lpars see), so that bonding can detect the link failure. This
is an option to ehea; by default, all internal ports are always carrier
up so that they can communicate with one another regardless of the
external port link state. To my knowledge, this is used with miimon,
not the arp monitor.
I don't know how SR-IOV operates in this regard (e.g., can VFs
fail independently from the PF?). It is somewhat different from your
case in that there is no equivalent to the PF in the ehea case. If the
PFs participate in the primary setting it will likely permit initial
connectivity, but I'm not sure if a PF plus all its VFs fail as a unit
(from bonding's point of view).
>For issue 3, the logical solution would seem to be some way of assigning
>a list of "valid" mac addresses to a given VF--like maybe all MAC
>addresses assigned to a VM or something. Anyone have any bright ideas?
There's an option to bonding, fail_over_mac, that modifies
bonding's handling of the slaves' MAC address(es). One setting,
"active" instructs bonding to make its MAC be whatever the currently
active slave's MAC is, never changing any of the slave's MAC addresses.
>I'm sure we're not the only ones running into this, so what are others
>doing? Is the only current option to use active/active with miimon?
I think you're at least close to the edge here; I've only done
some basic testing of bonding with SR-IOV, although I'm planning to do
some more early next week (and what you've found has been good input for
me, so thanks for that, at least).
I suspect that some bonding configurations are simply not going
to work at all; e.g., I'm not aware of any SR-IOV devices that implement
LACP on the internal switch, and in any event, it would have to create
aggregators that span across physical network devices to be really
useful.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] firmware: Remove obsolete Chelsio cxgb3 firmware
From: Paul Gortmaker @ 2012-08-02 20:40 UTC (permalink / raw)
To: Tim Gardner
Cc: David Miller, linux-kernel, ben, JBottomley, dan.j.williams, divy,
netdev
In-Reply-To: <501A728A.2070905@canonical.com>
On 12-08-02 08:28 AM, Tim Gardner wrote:
> On 08/02/2012 01:20 AM, David Miller wrote:
>>
>> "git am" refuses to apply this to current 'net':
>>
>> Applying: firmware: Remove obsolete Chelsio cxgb3 firmware
>> error: removal patch leaves file contents
>> error: firmware/cxgb3/t3fw-7.10.0.bin.ihex: patch does not apply
>>
>
> Paul Gortmaker suggested I use 'git format-patch --irreversible-delete'
> to produce shorter patches, but then even I can't reapply it.
The git folks originally designed it that way on purpose, (i.e. used
for review only) but it doesn't really need to be limited like that,
so I've proposed a fix and we'll see what the git folks have to say.
http://marc.info/?l=git&m=134394003916648&w=2
Paul.
--
>
> How about a pull request against net-next instead ?
>
> The following changes since commit 1a9b4993b70fb1884716902774dc9025b457760d:
>
> Merge branch 'upstream' of
> git://git.linux-mips.org/pub/scm/ralf/upstream-linus (2012-08-01
> 16:47:15 -0700)
>
> are available in the git repository at:
>
>
> git://kernel.ubuntu.com/rtg/net-next.git master
>
> for you to fetch changes up to 044b722f36a17bc5f7f472cc3246cb15a430bb0e:
>
> firmware: Remove obsolete Chelsio cxgb3 firmware (2012-08-02 06:23:25
> -0600)
>
> ----------------------------------------------------------------
> Tim Gardner (1):
> firmware: Remove obsolete Chelsio cxgb3 firmware
>
> firmware/Makefile | 1 -
> firmware/cxgb3/t3fw-7.10.0.bin.ihex | 1935
> -----------------------------------
> 2 files changed, 1936 deletions(-)
> delete mode 100644 firmware/cxgb3/t3fw-7.10.0.bin.ihex
>
^ permalink raw reply
* [PATCH] mlx4_en: add UFO support
From: Thadeu Lima de Souza Cascardo @ 2012-08-02 20:53 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Yevgeny Petrilin, Or Gerlitz,
Thadeu Lima de Souza Cascardo
Mellanox Ethernet adapters support Large Segmentation Offload for UDP
packets. The only change needed is using the proper header size when the
packet is UDP instead of TCP.
This significantly increases performance for large UDP packets on
platforms which have an expensive dma_map call, like pseries.
On a simple test with 64000 payload size, throughput has increased from
about 6Gbps to 9.5Gbps, while CPU use dropped from about 600% to about
80% or less, on a 8-core Power7 machine.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 7 ++++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index edd9cb8..59e808a 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1660,7 +1660,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
*/
dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
if (mdev->LSO_support)
- dev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
+ dev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO;
dev->vlan_features = dev->hw_features;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 019d856..2aad5a4 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -39,6 +39,7 @@
#include <linux/if_vlan.h>
#include <linux/vmalloc.h>
#include <linux/tcp.h>
+#include <linux/udp.h>
#include <linux/moduleparam.h>
#include "mlx4_en.h"
@@ -455,7 +456,11 @@ static int get_real_size(struct sk_buff *skb, struct net_device *dev,
int real_size;
if (skb_is_gso(skb)) {
- *lso_header_size = skb_transport_offset(skb) + tcp_hdrlen(skb);
+ *lso_header_size = skb_transport_offset(skb);
+ if (skb_shinfo(skb)->gso_type == SKB_GSO_UDP)
+ *lso_header_size += sizeof(struct udphdr);
+ else
+ *lso_header_size += tcp_hdrlen(skb);
real_size = CTRL_SIZE + skb_shinfo(skb)->nr_frags * DS_SIZE +
ALIGN(*lso_header_size + 4, DS_SIZE);
if (unlikely(*lso_header_size != skb_headlen(skb))) {
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Vlad Yasevich @ 2012-08-02 21:17 UTC (permalink / raw)
To: xufeng zhang
Cc: Xufeng Zhang, Neil Horman, sri, davem, linux-sctp, netdev,
linux-kernel
In-Reply-To: <50178061.4010709@windriver.com>
On 07/31/2012 02:51 AM, xufeng zhang wrote:
> Sorry, please ignore the above patch, there was an paste error.
> Please check the following patch.
> ============================================
> I'm wondering if the below solution is fine to you which is based on
> your changes.
> BTW, I have verified this patch and it works ok for all the situation,
> but only one problem persists:
> there is a potential that commands will exceeds SCTP_MAX_NUM_COMMANDS
> which happens during sending lots of small error DATA chunks.
>
I started thinking along the same vein, but was thinking that maybe it
makes sense to make error list more generic. I need to check the spec on
the ordering of ERROR chunks. If they are always after other control
chunks, then maybe make an error list and queue all errors there. Then
when sending control chunks, drain the control queue first, then the
error queue, and finally the data queue.
BTW, the patch below doesn't include the code to queue the error chunk
onto the new error queue.
-vlad
> Thanks,
> Xufeng Zhang
>
> ---
> include/net/sctp/command.h | 1 +
> include/net/sctp/structs.h | 3 +++
> net/sctp/outqueue.c | 7 +++++++
> net/sctp/sm_sideeffect.c | 16 ++++++++++++++++
> net/sctp/sm_statefuns.c | 17 ++++++++++++++---
> 5 files changed, 41 insertions(+), 3 deletions(-)
>
> diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
> index 712b3be..62c34f5 100644
> --- a/include/net/sctp/command.h
> +++ b/include/net/sctp/command.h
> @@ -110,6 +110,7 @@ typedef enum {
> SCTP_CMD_SEND_NEXT_ASCONF, /* Send the next ASCONF after ACK */
> SCTP_CMD_PURGE_ASCONF_QUEUE, /* Purge all asconf queues.*/
> SCTP_CMD_SET_ASOC, /* Restore association context */
> + SCTP_CMD_GEN_BAD_STREAM, /* Invalid Stream errors happened
> command */
> SCTP_CMD_LAST
> } sctp_verb_t;
>
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index fc5e600..3d218e0 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -1183,6 +1183,9 @@ struct sctp_outq {
> */
> struct list_head abandoned;
>
> + /* Put Invalid Stream error chunks on this list */
> + struct list_head bad_stream_err;
> +
> /* How many unackd bytes do we have in-flight? */
> __u32 outstanding_bytes;
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index e7aa177..1e87b0b 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -211,6 +211,7 @@ void sctp_outq_init(struct sctp_association *asoc,
> struct sctp_outq *q)
> INIT_LIST_HEAD(&q->retransmit);
> INIT_LIST_HEAD(&q->sacked);
> INIT_LIST_HEAD(&q->abandoned);
> + INIT_LIST_HEAD(&q->bad_stream_err);
>
> q->fast_rtx = 0;
> q->outstanding_bytes = 0;
> @@ -283,6 +284,12 @@ void sctp_outq_teardown(struct sctp_outq *q)
> list_del_init(&chunk->list);
> sctp_chunk_free(chunk);
> }
> +
> + /* Throw away any pending Invalid Stream error chunks */
> + list_for_each_entry_safe(chunk, tmp,&q->bad_stream_err, list) {
> + list_del_init(&chunk->list);
> + sctp_chunk_free(chunk);
> + }
> }
>
> /* Free the outqueue structure and any related pending chunks. */
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index fe99628..4698593 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -1060,6 +1060,18 @@ static void sctp_cmd_send_asconf(struct
> sctp_association *asoc)
> }
> }
>
> +static void sctp_cmd_make_inv_stream_err(sctp_cmd_seq_t *commands,
> + struct sctp_association *asoc)
> +{
> + struct sctp_chunk *err, *tmp;
> + struct sctp_outq *q =&asoc->outqueue;
> +
> + list_for_each_entry_safe(err, tmp,&q->bad_stream_err, list) {
> + list_del_init(&err->list);
> + sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> + SCTP_CHUNK(err));
> + }
> +}
>
> /* These three macros allow us to pull the debugging code out of the
> * main flow of sctp_do_sm() to keep attention focused on the real
> @@ -1724,6 +1736,10 @@ static int sctp_cmd_interpreter(sctp_event_t
> event_type,
> asoc = cmd->obj.asoc;
> break;
>
> + case SCTP_CMD_GEN_BAD_STREAM:
> + sctp_cmd_make_inv_stream_err(commands, asoc);
> + break;
> +
> default:
> pr_warn("Impossible command: %u, %p\n",
> cmd->verb, cmd->obj.ptr);
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index 9fca103..1c1bcd9 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -2967,8 +2967,14 @@ discard_force:
> return SCTP_DISPOSITION_DISCARD;
>
> discard_noforce:
> - if (chunk->end_of_packet)
> + if (chunk->end_of_packet) {
> + struct sctp_outq *q =&asoc->outqueue;
> sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK, force);
> + /* Queue the INVALID STREAM error after the SACK if one
> is needed. */
> + if (!list_empty(&q->bad_stream_err))
> + sctp_add_cmd_sf(commands, SCTP_CMD_GEN_BAD_STREAM,
> + SCTP_NULL());
> + }
>
> return SCTP_DISPOSITION_DISCARD;
> consume:
> @@ -3037,11 +3043,16 @@ sctp_disposition_t
> sctp_sf_eat_data_fast_4_4(const struct sctp_endpoint *ep,
> * with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown
> timer
> */
> if (chunk->end_of_packet) {
> + struct sctp_outq *q =&asoc->outqueue;
> /* We must delay the chunk creation since the cumulative
> * TSN has not been updated yet.
> */
> sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SHUTDOWN,
> SCTP_NULL());
> sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK,
> SCTP_FORCE());
> + /* Queue the INVALID STREAM error after the SACK if one
> is needed. */
> + if (!list_empty(&q->bad_stream_err))
> + sctp_add_cmd_sf(commands, SCTP_CMD_GEN_BAD_STREAM,
> + SCTP_NULL());
> sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART,
> SCTP_TO(SCTP_EVENT_TIMEOUT_T2_SHUTDOWN));
> }
> @@ -6136,6 +6147,7 @@ static int sctp_eat_data(const struct
> sctp_association *asoc,
> */
> sid = ntohs(data_hdr->stream);
> if (sid>= asoc->c.sinit_max_instreams) {
> + struct sctp_outq *q =&asoc->outqueue;
> /* Mark tsn as received even though we drop it */
> sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_TSN,
> SCTP_U32(tsn));
>
> @@ -6144,8 +6156,7 @@ static int sctp_eat_data(const struct
> sctp_association *asoc,
> sizeof(data_hdr->stream),
> sizeof(u16));
> if (err)
> - sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> - SCTP_CHUNK(err));
> + list_add_tail(&err->list,&q->bad_stream_err);
> return SCTP_IERROR_BAD_STREAM;
> }
>
^ permalink raw reply
* Re: discussion questions: SR-IOV, virtualization, and bonding
From: Chris Friesen @ 2012-08-02 22:26 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <17679.1343939453@death.nxdomain>
On 08/02/2012 02:30 PM, Jay Vosburgh wrote:
>
> Chris Friesen<chris.friesen@genband.com> wrote:
>> 2) If both the host and guest use active/backup but pick different
>> devices as the active, there is no traffic between host/guest over the
>> bond link. Packets are sent out the active and looped back internally
>> to arrive on the inactive, then skb_bond_should_drop() suppresses them.
>
> Just to be sure that I'm following this correctly, you're
> setting up active-backup bonds on the guest and the host. The guest
> sets its active slave to be a VF from "SR-IOV Device A," but the host
> sets its active slave to a PF from "SR-IOV Device B." Traffic from the
> guest to the host then arrives at the host's inactive slave (it's PF for
> "SR-IOV Device A") and is then dropped.
>
> Correct?
Yes, that's correct. The issue is that the internal switch on device A
knows nothing about device B. Ideally what should happen is that the
internal switch routes the packets out onto the wire so that they come
back in on device B and get routed up to the host. However, at least
with the Intel devices the internal switch has no learning capabilities.
The alternative is to have the external switch(es) configured to do the
loopback, but that puts some extra requirements on the selection of the
external switch.
>> So far the solutions to 1 seem to be either using arp validation (which
>> currently doesn't exist for loadbalancing modes) or else have the
>> underlying ethernet driver distinguish between packets coming from the
>> wire vs being looped back internally and have the bonding driver only
>> set last_rx for external packets.
>
> As discussed previously, e.g.,:
>
> http://marc.info/?l=linux-netdev&m=134316327912154&w=2
>
> implementing arp_validate for load balance modes is tricky at
> best, regardless of SR-IOV issues.
Yes, I should have referenced that discussion. I thought I'd include it
here with the other issues to group everything together.
> This is really a variation on the situation that led to the
> arp_validate functionality in the first place (that multiple instances
> of ARP monitor on a subnet can fool one another), except that the switch
> here is within the SR-IOV device and the various hosts are guests.
>
> The best long term solution is to have a user space API that
> provides link state input to bonding on a per-slave basis, and then some
> user space entity can perform whatever link monitoring method is
> appropriate (e.g., LLDP) and pass the results to bonding.
I think this has potential. This requires a virtual communication
channel between guest/host if we want the host to be able to influence
the guest's choice of active link, but I think that's not unreasonable.
Actually, couldn't we do this now? Turn off miimon and arpmon, then
just have the userspace thing write to
/sys/class/net/bondX/bonding/active_slave
>> For issue 2, it would seem beneficial for the host to be able to ensure
>> that the guest uses the same link as the active. I don't see a tidy
>> solution here. One somewhat messy possibility here is to have bonding
>> send a message to the standby PF which then tells all its VFs to fake
>> loss of carrier.
>
> There is no tidy solution here that I'm aware of; this has been
> a long standing concern in bladecenter type of network environments,
> wherein all blade "eth0" interfaces connect to one chassis switch, and
> all blade "eth1" interfaces connect to a different chassis switch. If
> those switches are not connected, then there may not be a path from
> blade A:eth0 to blade B:eth1. There is no simple mechanism to force a
> gang failover across multiple hosts.
In our blade server environment those two switches are indeed
cross-connected, so we haven't had to do gang-failover.
> Note that the ehea can propagate link failure of its external
> port (the one that connects to a "real" switch) to its internal ports
> (what the lpars see), so that bonding can detect the link failure. This
> is an option to ehea; by default, all internal ports are always carrier
> up so that they can communicate with one another regardless of the
> external port link state. To my knowledge, this is used with miimon,
> not the arp monitor.
>
> I don't know how SR-IOV operates in this regard (e.g., can VFs
> fail independently from the PF?). It is somewhat different from your
> case in that there is no equivalent to the PF in the ehea case. If the
> PFs participate in the primary setting it will likely permit initial
> connectivity, but I'm not sure if a PF plus all its VFs fail as a unit
> (from bonding's point of view).
With current Intel drivers at least, if the PF detects link failure it
fires a message to the VFs and they detect link failure within a short
time (milliseconds).
We can recommend the use of the "primary" option, but we don't always
have total control over what the guest does, and for some reason some of
them don't want to use "primary". I'm not sure why.
>> For issue 3, the logical solution would seem to be some way of assigning
>> a list of "valid" mac addresses to a given VF--like maybe all MAC
>> addresses assigned to a VM or something. Anyone have any bright ideas?
>
> There's an option to bonding, fail_over_mac, that modifies
> bonding's handling of the slaves' MAC address(es). One setting,
> "active" instructs bonding to make its MAC be whatever the currently
> active slave's MAC is, never changing any of the slave's MAC addresses.
Yes, I'm aware of that option. It does have drawbacks though, as
described in the bonding.txt docs.
>> I'm sure we're not the only ones running into this, so what are others
>> doing? Is the only current option to use active/active with miimon?
>
> I think you're at least close to the edge here; I've only done
> some basic testing of bonding with SR-IOV, although I'm planning to do
> some more early next week (and what you've found has been good input for
> me, so thanks for that, at least).
Glad we could help. :)
Chris
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: discussion questions: SR-IOV, virtualization, and bonding
From: Chris Friesen @ 2012-08-02 22:33 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <501AFEAD.10001@genband.com>
On 08/02/2012 04:26 PM, Chris Friesen wrote:
> On 08/02/2012 02:30 PM, Jay Vosburgh wrote:
>> The best long term solution is to have a user space API that
>> provides link state input to bonding on a per-slave basis, and then some
>> user space entity can perform whatever link monitoring method is
>> appropriate (e.g., LLDP) and pass the results to bonding.
>
> I think this has potential. This requires a virtual communication
> channel between guest/host if we want the host to be able to influence
> the guest's choice of active link, but I think that's not unreasonable.
>
> Actually, couldn't we do this now? Turn off miimon and arpmon, then just
> have the userspace thing write to /sys/class/net/bondX/bonding/active_slave
Hmm...looks like the bonding code requires either miimon or arpmon. I
wonder if setting miimon to INT_MAX might work, at least for some
bonding modes.
Chris
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: CPU: 0 Not tainted (3.1.9+ #1) when ifconfig rose0 down
From: Eric W. Biederman @ 2012-08-02 22:55 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: linux-hams, Linux Netdev List
In-Reply-To: <5017E786.5000102@free.fr>
Bernard Pidoux <bernard.pidoux@free.fr> writes:
> Hi,
>
> I observe systematically a kernel panic when I try to shutdown rose0 device
> using ifconfig rose0 down
>
> This is happening on two very different ROSE implementation, one is on a machine
> with x86-64 kernel 4.6.3 on an Intel core 2 duo CPU
> the other is on a RaspBerry Pi with Raspbian and 3.1.9+ wheezy kernel
> recompiled with AX.25 modules (ax25, rose, netrom, 6pack, kiss) enabled.
>
> Here is an image of the screen dump :
>
> http://f6bvp.org/photos/rose_device_event.JPG
For some reason I can not connect f6bvp.org.
> It can be noticed that PC is at rose_device_event and
> LR is at sock_def_wakeup
>
> One thing to be noticed is that when I close before all ROSE and AX.25
> applications, there are still a few populated sockets, probably for one of the
> program did not close the sockets properly.
>
> I that case, does rose module should accept to shutdown rose0 device ?
> However, I guess that it should not create a kernel panic due to a kernel NULL
> pointer.
No. The kernel should not panic.
> I don't know what to do in order to debug that issue.
I assume that rose is interesting to you and you would like for it to
work better?
In general you can read the code and figure out what it is doing ref
counting wise. It doesn't look like anyone has done much with the rose
code for years except very basic maintenance across the kernel. It
scares me to know that I was the last one to touch the rose code.
Part of what is happening at the time of the panic is
unregister_netdevice_notifier now generates synthetic removal for all of
the network devices in the system to remove the need for a special path
to handle network device removal in modules.
Unfortunately it looks like one of those modules is a problem.
You might want to simply try moving unregister_netdevice_notifier a bit
earlier in rose_exit and see if that helps. Otherwise I would recommend
instrumenting the code up with some printk so you can understand what
part of unregistration is failing.
Eric
^ permalink raw reply
* Re: [E1000-devel] discussion questions: SR-IOV, virtualization, and bonding
From: Jay Vosburgh @ 2012-08-02 23:01 UTC (permalink / raw)
To: Chris Friesen; +Cc: e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <501B0037.1010804@genband.com>
Chris Friesen <chris.friesen@genband.com> wrote:
>On 08/02/2012 04:26 PM, Chris Friesen wrote:
>> On 08/02/2012 02:30 PM, Jay Vosburgh wrote:
>
>>> The best long term solution is to have a user space API that
>>> provides link state input to bonding on a per-slave basis, and then some
>>> user space entity can perform whatever link monitoring method is
>>> appropriate (e.g., LLDP) and pass the results to bonding.
>>
>> I think this has potential. This requires a virtual communication
>> channel between guest/host if we want the host to be able to influence
>> the guest's choice of active link, but I think that's not unreasonable.
Not necessarily, if something like LLDP runs across the virtual
link between the guest and slave, then the guest will notice when the
link goes down (although perhaps not very quickly). I'm pretty sure the
infrastructure to make LLDP work on inactive slaves is already there; as
I recall, the "no wildcard" or "deliver exact" business in the receive
path is at least partially for LLDP.
Still, though, isn't "influence the guest's choice" pretty much
satisified by having the VF interface go carrier down in the guest when
the host wants it to? Or are you thinking about more fine grained than
that?
>> Actually, couldn't we do this now? Turn off miimon and arpmon, then just
>> have the userspace thing write to /sys/class/net/bondX/bonding/active_slave
That might work for active-backup mode, yes, although it may not
handle the case when all slaves have failed if "failed" does not include
the slave being carrier down. It's not quite the same thing as input to
the link monitoring logic.
>Hmm...looks like the bonding code requires either miimon or arpmon. I
>wonder if setting miimon to INT_MAX might work, at least for some bonding
>modes.
Not true; it's legal to leave miimon and arp_interval set to 0.
Older versions of bonding will whine about it, but let you do it; in
mainline, it's a debug message you have to choose to turn on (because
current versions of initscripts, et al, create the bond first, and then
set those options, so it tended to whine all the time).
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: CPU: 0 Not tainted (3.1.9+ #1) when ifconfig rose0 down
From: Eric W. Biederman @ 2012-08-02 23:03 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: linux-hams, Linux Netdev List
In-Reply-To: <5017F96B.1060701@free.fr>
Bernard Pidoux <bernard.pidoux@free.fr> writes:
> Here is a complementary observation.
> Trying to remove rose module with rmmod rose did not create any kernel panic.
> However, there is an endless message from the kernel saying :
>
> Message from syslogd@raspberrypi at Jul 31 17:22:40 ...
> kernel:[ 831.579007] unregister_netdevice: waiting for rose0 to become
> free. Usage count = 23
>
> Message from syslogd@raspberrypi at Jul 31 17:22:50 ...
> kernel:[ 841.739390] unregister_netdevice: waiting for rose0 to become
> free. Usage count = 23
>
> Message from syslogd@raspberrypi at Jul 31 17:23:00 ...
> kernel:[ 851.899758] unregister_netdevice: waiting for rose0 to become
> free. Usage count = 23
> .....
>
> As observed at many occasions, count number seems to be random ! and
> the same message keeps going without any change of count number.
> At the same time, there is no possibility to recover the command line on any
> console.
> However I could loggin via ssh and I noticed that rose0 device is actually no
> more in the ifconfig list.
>
> If I try to remove rose with rmmod rose I get :
>
> root@raspberrypi:/home/pi# rmmod rose
> libkmod: ERROR ../libkmod/libkmod-module.c:753 kmod_module_remove_module: could
> not remove 'rose': Device or resource busy
> Error: could not remove module rose: Device or resource busy
>
>
> Does this help ?
Something presumably in the rose code is leaking a reference to the rose
device. That is probably a separate bug than your other one, but it may
be related. These are some of my least favorite bugs to track down.
That said in rose there is only one call to dev_hold and only one call
to dev_put.
Hmm. Looking at it dev_hold happens in rose_dev_get, and of which there
are several callers and only one of those callers calls dev_put. So
it should just be a matter of adding some more dev_put calls in the
appropriate places.
The usage in rose_loopback_timer looks easy to fix, the usage in
rose_bind seems more of a challenge.
Are you enough of a developer to take that observation and look at
the code and fix it?
Eric
^ permalink raw reply
* Re: [PATCH 0/4] net/mlx4: Fixes to mlx4 driver
From: David Miller @ 2012-08-02 23:12 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <1343921456-19180-1-git-send-email-yevgenyp@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Thu, 2 Aug 2012 18:30:52 +0300
> Yevgeny Petrilin (3):
> net/mlx4_en: Setting the NETIF_F_GRO flag back to dev->hw_features
As pointed out, this isn't a bug.
You just made this change purely via code inspection, and that's very
disappointing because this would have been so simple to validate.
^ permalink raw reply
* Re: [E1000-devel] discussion questions: SR-IOV, virtualization, and bonding
From: Chris Friesen @ 2012-08-02 23:15 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <20421.1343948491@death.nxdomain>
On 08/02/2012 05:01 PM, Jay Vosburgh wrote:
> Chris Friesen<chris.friesen@genband.com> wrote:
> Still, though, isn't "influence the guest's choice" pretty much
> satisified by having the VF interface go carrier down in the guest when
> the host wants it to? Or are you thinking about more fine grained than
> that?
That was the first thing we started looking at.
It would actually be better technically (since it would use the
back-channel between PF and VFs rather than needing an explicit virtual
network link between host/guest) but it would require work in all the
PF/VF drivers. We'd need to get support from all the driver maintainers.
The main advantage of doing it in bonding is that we'd only need to
modify the code in one place.
Chris
^ permalink raw reply
* Re: [PATCH 1/1] ipv6 : ip6mr.c : Fix can't match the IPv6 multicast packets with input net device in netfilter FORWARD chain.
From: David Miller @ 2012-08-02 23:20 UTC (permalink / raw)
To: mypopydev; +Cc: kuznet, jmorris, yoshfuji, netdev
In-Reply-To: <1343912455-4444-1-git-send-email-mypopydev@gmail.com>
From: Jun Zhao <mypopydev@gmail.com>
Date: Thu, 2 Aug 2012 21:00:55 +0800
> Current kernel change the skb's net device with output device before netfilter FORWARD chain,
> that will lead to can't match the IPv6 multicast packets with input net device in netfilter
> FORWARD chain.
>
> the test case for reproduce this issue as follow:
>
> IPv6 multicast udp stream from eth0(input device) to eth1(output device)
Your change means we now can't match on the VIF device in this situation.
I'm not applying this patch, it breaks as much as it fixes.
^ permalink raw reply
* Re: [PATCH] isdnloop: fix and simplify isdnloop_init()
From: David Miller @ 2012-08-02 23:21 UTC (permalink / raw)
To: fengguang.wu
Cc: netdev, dan.carpenter, gregkh, devel, joe, isdn, linux-kernel
In-Reply-To: <20120802110543.GA21745@localhost>
From: Fengguang Wu <fengguang.wu@intel.com>
Date: Thu, 2 Aug 2012 19:05:43 +0800
> Fix a buffer overflow bug by removing the revision transform code.
>
> [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
> [ 22.097508] isdnloop: (loop0) virtual card added
> [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
> [ 22.174400]
> [ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
> [ 22.624071] Call Trace:
> [ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
> [ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
> [ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
> [ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
The reason the "$Revision ..." prefix is there is so that automated
version control tools will change the string automatically when code
is committed in CVS.
In the GIT era this revision style is obsolete.
Therefore you might as well just delete this crap altogether.
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: David Miller @ 2012-08-02 23:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: ebiederm, xemul, netdev
In-Reply-To: <1343903310.9299.184.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 02 Aug 2012 12:28:30 +0200
> Strange because I see no false sharing on this ifindex location for
> loopback device.
Are you sure netdev->rx_dropped isn't being incremented? That appears
as if it would land on the same cache line as netdev->ifindex.
^ permalink raw reply
* Re: discussion questions: SR-IOV, virtualization, and bonding
From: Jay Vosburgh @ 2012-08-02 23:36 UTC (permalink / raw)
To: Chris Friesen; +Cc: e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <501B0A10.8030703@genband.com>
Chris Friesen <chris.friesen@genband.com> wrote:
>On 08/02/2012 05:01 PM, Jay Vosburgh wrote:
>> Chris Friesen<chris.friesen@genband.com> wrote:
>
>> Still, though, isn't "influence the guest's choice" pretty much
>> satisified by having the VF interface go carrier down in the guest when
>> the host wants it to? Or are you thinking about more fine grained than
>> that?
>
>That was the first thing we started looking at.
>
>It would actually be better technically (since it would use the
>back-channel between PF and VFs rather than needing an explicit virtual
>network link between host/guest) but it would require work in all the
>PF/VF drivers. We'd need to get support from all the driver maintainers.
It might also be better (for a different definition of "better")
to use the virtual network link and do more functionality in a generic
user space piece that's not in the kernel and wouldn't require special
driver support. Either way, I imagine there's going to have to be some
sort of message passing going on.
>The main advantage of doing it in bonding is that we'd only need to modify
>the code in one place.
As long as it works with VLANs bonded together; that seems to be
more common these days.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: David Miller @ 2012-08-02 23:37 UTC (permalink / raw)
To: ebiederm; +Cc: eric.dumazet, xemul, netdev
In-Reply-To: <87wr1h35zg.fsf@xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 02 Aug 2012 04:09:39 -0700
> Eric Dumazet <eric.dumazet@gmail.com> writes:
>
>> If ifindex are per network space, I guess we'll need to change
>> arp_hashfn() or else we'll use some slots more than others.
>
> Darn. I hate being right about there being a few places to fix
> up.
>
> ndisc_hashfn also has the same limitation.
And netlabel's inteface hashing as well.
LLC works with ifindex hashing and is not namespace aware. It's
should therefore limited to &init_net and therefore OK. Likewise
for the CAN code.
^ permalink raw reply
* ..656...565..265...356..
From: sodduuve @ 2012-08-03 0:14 UTC (permalink / raw)
To: yuexianana
负责人您好：
我公司有（国—地）税/票据代开，如有这方面的需
要请联系。若有打扰，请多包涵）谢谢。
联系人：王经理
手 机：13538292585
Q Q:1060046785
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: xufeng zhang @ 2012-08-03 2:24 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Xufeng Zhang, Neil Horman, sri, davem, linux-sctp, netdev,
linux-kernel
In-Reply-To: <501AEE5E.8090303@gmail.com>
On 08/03/2012 05:17 AM, Vlad Yasevich wrote:
> On 07/31/2012 02:51 AM, xufeng zhang wrote:
>> Sorry, please ignore the above patch, there was an paste error.
>> Please check the following patch.
>> ============================================
>> I'm wondering if the below solution is fine to you which is based on
>> your changes.
>> BTW, I have verified this patch and it works ok for all the situation,
>> but only one problem persists:
>> there is a potential that commands will exceeds SCTP_MAX_NUM_COMMANDS
>> which happens during sending lots of small error DATA chunks.
>>
>
> I started thinking along the same vein, but was thinking that maybe it
> makes sense to make error list more generic. I need to check the spec
> on the ordering of ERROR chunks. If they are always after other
> control chunks, then maybe make an error list and queue all errors
> there. Then when sending control chunks, drain the control queue
> first, then the error queue, and finally the data queue.
I didn't find the explicitly bundling order description in spec for
other ERROR chunks,
but it's reasonable to do this.
Anyway, I'll wait for your final solution.
Thanks,
Xufeng Zhang
>
> BTW, the patch below doesn't include the code to queue the error chunk
> onto the new error queue.
>
> -vlad
>
>> Thanks,
>> Xufeng Zhang
>>
>> ---
>> include/net/sctp/command.h | 1 +
>> include/net/sctp/structs.h | 3 +++
>> net/sctp/outqueue.c | 7 +++++++
>> net/sctp/sm_sideeffect.c | 16 ++++++++++++++++
>> net/sctp/sm_statefuns.c | 17 ++++++++++++++---
>> 5 files changed, 41 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
>> index 712b3be..62c34f5 100644
>> --- a/include/net/sctp/command.h
>> +++ b/include/net/sctp/command.h
>> @@ -110,6 +110,7 @@ typedef enum {
>> SCTP_CMD_SEND_NEXT_ASCONF, /* Send the next ASCONF after ACK */
>> SCTP_CMD_PURGE_ASCONF_QUEUE, /* Purge all asconf queues.*/
>> SCTP_CMD_SET_ASOC, /* Restore association context */
>> + SCTP_CMD_GEN_BAD_STREAM, /* Invalid Stream errors happened
>> command */
>> SCTP_CMD_LAST
>> } sctp_verb_t;
>>
>> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
>> index fc5e600..3d218e0 100644
>> --- a/include/net/sctp/structs.h
>> +++ b/include/net/sctp/structs.h
>> @@ -1183,6 +1183,9 @@ struct sctp_outq {
>> */
>> struct list_head abandoned;
>>
>> + /* Put Invalid Stream error chunks on this list */
>> + struct list_head bad_stream_err;
>> +
>> /* How many unackd bytes do we have in-flight? */
>> __u32 outstanding_bytes;
>>
>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>> index e7aa177..1e87b0b 100644
>> --- a/net/sctp/outqueue.c
>> +++ b/net/sctp/outqueue.c
>> @@ -211,6 +211,7 @@ void sctp_outq_init(struct sctp_association *asoc,
>> struct sctp_outq *q)
>> INIT_LIST_HEAD(&q->retransmit);
>> INIT_LIST_HEAD(&q->sacked);
>> INIT_LIST_HEAD(&q->abandoned);
>> + INIT_LIST_HEAD(&q->bad_stream_err);
>>
>> q->fast_rtx = 0;
>> q->outstanding_bytes = 0;
>> @@ -283,6 +284,12 @@ void sctp_outq_teardown(struct sctp_outq *q)
>> list_del_init(&chunk->list);
>> sctp_chunk_free(chunk);
>> }
>> +
>> + /* Throw away any pending Invalid Stream error chunks */
>> + list_for_each_entry_safe(chunk, tmp,&q->bad_stream_err, list) {
>> + list_del_init(&chunk->list);
>> + sctp_chunk_free(chunk);
>> + }
>> }
>>
>> /* Free the outqueue structure and any related pending chunks. */
>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>> index fe99628..4698593 100644
>> --- a/net/sctp/sm_sideeffect.c
>> +++ b/net/sctp/sm_sideeffect.c
>> @@ -1060,6 +1060,18 @@ static void sctp_cmd_send_asconf(struct
>> sctp_association *asoc)
>> }
>> }
>>
>> +static void sctp_cmd_make_inv_stream_err(sctp_cmd_seq_t *commands,
>> + struct sctp_association *asoc)
>> +{
>> + struct sctp_chunk *err, *tmp;
>> + struct sctp_outq *q =&asoc->outqueue;
>> +
>> + list_for_each_entry_safe(err, tmp,&q->bad_stream_err, list) {
>> + list_del_init(&err->list);
>> + sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>> + SCTP_CHUNK(err));
>> + }
>> +}
>>
>> /* These three macros allow us to pull the debugging code out of the
>> * main flow of sctp_do_sm() to keep attention focused on the real
>> @@ -1724,6 +1736,10 @@ static int sctp_cmd_interpreter(sctp_event_t
>> event_type,
>> asoc = cmd->obj.asoc;
>> break;
>>
>> + case SCTP_CMD_GEN_BAD_STREAM:
>> + sctp_cmd_make_inv_stream_err(commands, asoc);
>> + break;
>> +
>> default:
>> pr_warn("Impossible command: %u, %p\n",
>> cmd->verb, cmd->obj.ptr);
>> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
>> index 9fca103..1c1bcd9 100644
>> --- a/net/sctp/sm_statefuns.c
>> +++ b/net/sctp/sm_statefuns.c
>> @@ -2967,8 +2967,14 @@ discard_force:
>> return SCTP_DISPOSITION_DISCARD;
>>
>> discard_noforce:
>> - if (chunk->end_of_packet)
>> + if (chunk->end_of_packet) {
>> + struct sctp_outq *q =&asoc->outqueue;
>> sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK, force);
>> + /* Queue the INVALID STREAM error after the SACK if one
>> is needed. */
>> + if (!list_empty(&q->bad_stream_err))
>> + sctp_add_cmd_sf(commands,
>> SCTP_CMD_GEN_BAD_STREAM,
>> + SCTP_NULL());
>> + }
>>
>> return SCTP_DISPOSITION_DISCARD;
>> consume:
>> @@ -3037,11 +3043,16 @@ sctp_disposition_t
>> sctp_sf_eat_data_fast_4_4(const struct sctp_endpoint *ep,
>> * with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown
>> timer
>> */
>> if (chunk->end_of_packet) {
>> + struct sctp_outq *q =&asoc->outqueue;
>> /* We must delay the chunk creation since the
>> cumulative
>> * TSN has not been updated yet.
>> */
>> sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SHUTDOWN,
>> SCTP_NULL());
>> sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK,
>> SCTP_FORCE());
>> + /* Queue the INVALID STREAM error after the SACK if one
>> is needed. */
>> + if (!list_empty(&q->bad_stream_err))
>> + sctp_add_cmd_sf(commands,
>> SCTP_CMD_GEN_BAD_STREAM,
>> + SCTP_NULL());
>> sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART,
>>
>> SCTP_TO(SCTP_EVENT_TIMEOUT_T2_SHUTDOWN));
>> }
>> @@ -6136,6 +6147,7 @@ static int sctp_eat_data(const struct
>> sctp_association *asoc,
>> */
>> sid = ntohs(data_hdr->stream);
>> if (sid>= asoc->c.sinit_max_instreams) {
>> + struct sctp_outq *q =&asoc->outqueue;
>> /* Mark tsn as received even though we drop it */
>> sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_TSN,
>> SCTP_U32(tsn));
>>
>> @@ -6144,8 +6156,7 @@ static int sctp_eat_data(const struct
>> sctp_association *asoc,
>> sizeof(data_hdr->stream),
>> sizeof(u16));
>> if (err)
>> - sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>> - SCTP_CHUNK(err));
>> + list_add_tail(&err->list,&q->bad_stream_err);
>> return SCTP_IERROR_BAD_STREAM;
>> }
>>
>
>
^ permalink raw reply
* Re: [E1000-devel] discussion questions: SR-IOV, virtualization, and bonding
From: John Fastabend @ 2012-08-03 4:50 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Chris Friesen, e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <20421.1343948491@death.nxdomain>
On 8/2/2012 4:01 PM, Jay Vosburgh wrote:
> Chris Friesen <chris.friesen@genband.com> wrote:
>
>> On 08/02/2012 04:26 PM, Chris Friesen wrote:
>>> On 08/02/2012 02:30 PM, Jay Vosburgh wrote:
>>
>>>> The best long term solution is to have a user space API that
>>>> provides link state input to bonding on a per-slave basis, and then some
>>>> user space entity can perform whatever link monitoring method is
>>>> appropriate (e.g., LLDP) and pass the results to bonding.
>>>
>>> I think this has potential. This requires a virtual communication
>>> channel between guest/host if we want the host to be able to influence
>>> the guest's choice of active link, but I think that's not unreasonable.
>
> Not necessarily, if something like LLDP runs across the virtual
> link between the guest and slave, then the guest will notice when the
> link goes down (although perhaps not very quickly). I'm pretty sure the
> infrastructure to make LLDP work on inactive slaves is already there; as
> I recall, the "no wildcard" or "deliver exact" business in the receive
> path is at least partially for LLDP.
Right we run LLDP over the inactive bond. However because LLDP
uses nearest customer bridge, nearest bridge, or neareast non-tpmr
addresses it should be dropped by switching components. The problem
with having VMs send LLDP and _not_ dropping the packets is it looks
like multiple neighbors to the peer. The point is there is really an
edge relay like component in the hardware with SR-IOV. So likely using
LLDP do to do this wouldn't work
If you happen to have the 2010 802.1Q rev section 8.6.3 "frame
filtering" has some more details. The 802.1AB spec has details on the
multiple neighbor case.
>
> Still, though, isn't "influence the guest's choice" pretty much
> satisified by having the VF interface go carrier down in the guest when
> the host wants it to? Or are you thinking about more fine grained than
> that?
>
Perhaps one argument against this is if the hardware supports loopback
modes or the edge relay in the hardware is acting like a VEB it may
still be possible to support VF to VF traffic even if the external link
is down. Not sure how useful this is though or if any existing hardware
even supports it.
Just in case its not clear (it might not be) an edge relay (ER) is
defined in the new 802.1Qbg-2012 spec. "An ER supports local relay
among virtual stations and/or between a virtual station and other
stations on a bridged LAN". Similar to a bridge but without spanning
tree operations.
.John
^ permalink raw reply
* Re: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Vaibhav Hiremath @ 2012-08-03 5:16 UTC (permalink / raw)
To: Daniel Mack
Cc: netdev, mugunthanvnm, devicetree-discuss, koen, linux-arm-kernel
In-Reply-To: <1343936616-29318-1-git-send-email-zonque@gmail.com>
On 8/3/2012 1:13 AM, Daniel Mack wrote:
> Make the driver control the device clocks. Appearantly, the Davinci
> platform probes this driver with the clock all powered up, but on OMAP,
> this isn't the case.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> drivers/net/ethernet/ti/davinci_mdio.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> index cd7ee20..b4b6015 100644
> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> @@ -332,6 +332,8 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
> goto bail_out;
> }
>
> + clk_enable(data->clk);
> +
> dev_set_drvdata(dev, data);
> data->dev = dev;
> spin_lock_init(&data->lock);
> @@ -379,8 +381,11 @@ bail_out:
> if (data->bus)
> mdiobus_free(data->bus);
>
> - if (data->clk)
> + if (data->clk) {
> + clk_disable(data->clk);
> clk_put(data->clk);
> + }
> +
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> @@ -397,8 +402,11 @@ static int __devexit davinci_mdio_remove(struct platform_device *pdev)
> if (data->bus)
> mdiobus_free(data->bus);
>
> - if (data->clk)
> + if (data->clk) {
> + clk_disable(data->clk);
> clk_put(data->clk);
> + }
> +
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> @@ -427,6 +435,8 @@ static int davinci_mdio_suspend(struct device *dev)
> data->suspended = true;
> spin_unlock(&data->lock);
>
> + clk_disable(data->clk);
> +
> return 0;
> }
>
> @@ -435,6 +445,8 @@ static int davinci_mdio_resume(struct device *dev)
> struct davinci_mdio_data *data = dev_get_drvdata(dev);
> u32 ctrl;
>
> + clk_enable(data->clk);
> +
Danial,
I would request you to wait for this, its not that simple and straight.
And once you migrate to runtime PM you don't need clk_enable/disable,
this should get handled under runtime PM api's.
Also have you read my another email post -
http://comments.gmane.org/gmane.linux.ports.arm.omap/80796
Certainly, with respect to CPSW & MDIO, this patch is not enough and
requires further investigation. I have started looking at this and
hopefully will have some solution soon...
Thanks,
Vaibhav
^ 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