* 0432..180..52882...2004..
From: eef @ 2012-08-03 6:04 UTC (permalink / raw)
To: ppechmann
经理/财务您好！
我司可代开全国各地普通(国-地税)发&票，
点数优惠，承诺绝对真票，可验证后再付款。
（若打扰，请谅解）。
聯系人:杨小姐
手 機: 13818893119
Q Q: 925805893
^ 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: Jun Zhao @ 2012-08-03 6:10 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, jmorris, yoshfuji, netdev
In-Reply-To: <20120802.162015.2106150087918919160.davem@davemloft.net>
On Thu, 2012-08-02 at 16:20 -0700, David Miller wrote:
> 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.
Hi, David:
Maybe I need to used conservative approach to fix it and don't breaks
much more, I will supply the version 2 patch for this issue.
Tks.
^ permalink raw reply
* RE: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Hiremath, Vaibhav @ 2012-08-03 5:53 UTC (permalink / raw)
To: Daniel Mack
Cc: netdev@vger.kernel.org, N, Mugunthan V,
devicetree-discuss@lists.ozlabs.org, koen@dominion.thruhere.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <501B6020.7090502@gmail.com>
On Fri, Aug 03, 2012 at 10:52:40, Daniel Mack wrote:
> On 03.08.2012 07:16, Vaibhav Hiremath wrote:
> >
> >
> > 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.
>
> As I said, it can be dropped.
>
> > 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...
>
> Ok, no problem. We certainly need the DT bindings for davinci_mdio. With
> that applied, and the hwmod added (in the patch I posted yesterday), I
> can at least mount the rootfs via NFS, which is all I currently need.
>
>
I certainly understand your requirement here.
Actually this is not the only device we have, the same issue is applicable
to PWM subsystem available in AM335x. Hopefully I should have something soon
on this.
Thanks,
Vaibhav
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: Eric Dumazet @ 2012-08-03 5:51 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, xemul, netdev
In-Reply-To: <1343972729.9299.596.camel@edumazet-glaptop>
On Fri, 2012-08-03 at 07:45 +0200, Eric Dumazet wrote:
> Yes I am sure (by the way my output device was dummy0, not lo, but its
> the same for the case here)
Of course, the ifindex was related to lo, sorry for the confusion,
-ENOCOFFEE_YET_THIS_MORNING
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: Eric Dumazet @ 2012-08-03 5:45 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, xemul, netdev
In-Reply-To: <20120802.162601.2080519313891137444.davem@davemloft.net>
On Thu, 2012-08-02 at 16:26 -0700, David Miller wrote:
> 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.
>
Yes I am sure (by the way my output device was dummy0, not lo, but its
the same for the case here)
offsetof(struct net_device, features)=0x80
... (all features are mostly read only)
offsetof(struct net_device, ifindex)=0xa0
struct net_device_stats stats; is untouched on dummy device
offsetof(struct net_device, rx_dropped)=0x160
So thats only the dereference done million times per second that show in
the profiles, even if cache lines are clean and in cpu cache.
I see that even more clear in the IN_DEV_ROUTE_LOCALNET(in_dev) macro in
ip_route_input_slow(), doing so many derefs :
Its actually faster to avoid it, if we already have the net pointer in
hand : IN_DEV_NET_ROUTE_LOCALNET(in_dev, net)
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 67f9dda..d032780 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -104,9 +104,14 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
#define IN_DEV_ANDCONF(in_dev, attr) \
(IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr) && \
IN_DEV_CONF_GET((in_dev), attr))
-#define IN_DEV_ORCONF(in_dev, attr) \
- (IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr) || \
+
+#define IN_DEV_NET_ORCONF(in_dev, net, attr) \
+ (IPV4_DEVCONF_ALL(net, attr) || \
IN_DEV_CONF_GET((in_dev), attr))
+
+#define IN_DEV_ORCONF(in_dev, attr) \
+ IN_DEV_NET_ORCONF(in_dev, dev_net(in_dev->dev), attr)
+
#define IN_DEV_MAXCONF(in_dev, attr) \
(max(IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr), \
IN_DEV_CONF_GET((in_dev), attr)))
@@ -133,6 +138,8 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
IN_DEV_ORCONF((in_dev), \
PROMOTE_SECONDARIES)
#define IN_DEV_ROUTE_LOCALNET(in_dev) IN_DEV_ORCONF(in_dev, ROUTE_LOCALNET)
+#define IN_DEV_NET_ROUTE_LOCALNET(in_dev, net) \
+ IN_DEV_NET_ORCONF(in_dev, net, ROUTE_LOCALNET)
#define IN_DEV_RX_REDIRECTS(in_dev) \
((IN_DEV_FORWARD(in_dev) && \
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index e4ba974..5e88e3b 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1587,13 +1587,11 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
if (ipv4_is_zeronet(daddr))
goto martian_destination;
- if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev))) {
- if (ipv4_is_loopback(daddr))
- goto martian_destination;
+ if (ipv4_is_loopback(daddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
+ goto martian_destination;
- if (ipv4_is_loopback(saddr))
- goto martian_source;
- }
+ if (ipv4_is_loopback(saddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
+ goto martian_source;
/*
* Now we are ready to route packet.
^ permalink raw reply related
* Re: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Daniel Mack @ 2012-08-03 5:22 UTC (permalink / raw)
To: Vaibhav Hiremath
Cc: netdev, mugunthanvnm, devicetree-discuss, koen, linux-arm-kernel
In-Reply-To: <501B5EC1.7010304@ti.com>
On 03.08.2012 07:16, Vaibhav Hiremath wrote:
>
>
> 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.
As I said, it can be dropped.
> 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...
Ok, no problem. We certainly need the DT bindings for davinci_mdio. With
that applied, and the hwmod added (in the patch I posted yesterday), I
can at least mount the rootfs via NFS, which is all I currently need.
Best regards,
Daniel
^ 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
* 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] 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
* ..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 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
* 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: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: [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/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: [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 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: 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: [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 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: 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: 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: [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
* [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] 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
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