* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Sowmini Varadhan @ 2016-03-30 20:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesse Brandeburg, Alexander Duyck, Alexander Duyck, Netdev,
intel-wired-lan, Jeff Kirsher
In-Reply-To: <1459368904.6473.207.camel@edumazet-glaptop3.roam.corp.google.com>
On (03/30/16 13:15), Eric Dumazet wrote:
> You might try netperf -t TCP_SENDFILE -- -m 150
>
> to let netperf use sendfile() on small frags.
that still did not reproduce it but let me try beating on
that approach with more permutations.
BTW, another data-point that may help debug this: even with i40e,
if you use the "-o" option to the rds-stress invocation, there are
no problems: the "-o" option enforces uni-directional data
transfer, so one side is pure-Tx, other side is pure-Rx.
It is only when both sides simultaneously do both Tx and Rx
on the tcp socket that you see the issue. I dont know if
that provides any clues.
--Sowmini
^ permalink raw reply
* Re: [PATCH] sctp: flush if we can't fit another DATA chunk
From: Neil Horman @ 2016-03-30 20:32 UTC (permalink / raw)
To: David Miller; +Cc: marcelo.leitner, netdev, vyasevich, linux-sctp
In-Reply-To: <20160330.154622.1322506750240048120.davem@davemloft.net>
On Wed, Mar 30, 2016 at 03:46:22PM -0400, David Miller wrote:
> From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Date: Tue, 29 Mar 2016 10:41:25 -0300
>
> > There is no point in delaying the packet if we can't fit a single byte
> > of data on it anymore. So lets just reduce the threshold by the amount
> > that a data chunk with 4 bytes (rounding) would use.
> >
> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> > ---
> > net/sctp/output.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/sctp/output.c b/net/sctp/output.c
> > index 97745351d58c2fb32b9f9b57d61831d7724d83b2..c518569123ce42a8f21f80754756306c39875013 100644
> > --- a/net/sctp/output.c
> > +++ b/net/sctp/output.c
> > @@ -705,7 +705,8 @@ static sctp_xmit_t sctp_packet_can_append_data(struct sctp_packet *packet,
> > /* Check whether this chunk and all the rest of pending data will fit
> > * or delay in hopes of bundling a full sized packet.
> > */
> > - if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
> > + if (chunk->skb->len + q->out_qlen >
> > + maxsize - packet->overhead - sizeof(sctp_data_chunk_t) - 4)
>
> There is no maxsize in this function.
>
> You must generate and test your patches against my networking tree.
>
> Neil, how were you able to see where 'maxsize' is and how it's even
> calculated before determining that this change is correct?
>
Shit, sorry, dave, I trusted that Marcello built and tested the patch, and
reviewed it based on the validity of the math (which making assumptions for what
maxsize was, should be correct). No exuse, I screwed up.
Neil
> Please don't ACK patches you really didn't verify in any way at all,
> thanks. It's better to have no reviews than bad reviews, because ACKs
> are supposed to give me a reason to be more confident in the change.
>
> Marcelo, I'm ignoring the rest of your SCTP changes, you have to get
> your act together.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next] tcp: remove cwnd moderation after recovery
From: Yuchung Cheng @ 2016-03-30 20:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, netdev, Matt Mathis, Neal Cardwell,
Soheil Hassas Yeganeh
In-Reply-To: <20160329173545.5fe0ae8b@xeon-e3>
On Tue, Mar 29, 2016 at 5:35 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Tue, 29 Mar 2016 17:15:52 -0700
> Yuchung Cheng <ycheng@google.com> wrote:
>
>> For non-SACK connections, cwnd is lowered to inflight plus 3 packets
>> when the recovery ends. This is an optional feature in the NewReno
>> RFC 2582 to reduce the potential burst when cwnd is "re-opened"
>> after recovery and inflight is low.
>>
>> This feature is questionably effective because of PRR: when
>> the recovery ends (i.e., snd_una == high_seq) NewReno holds the
>> CA_Recovery state for another round trip to prevent false fast
>> retransmits. But if the inflight is low, PRR will overwrite the
>> moderated cwnd in tcp_cwnd_reduction() later.
>>
>> On the other hand, if the recovery ends because the sender
>> detects the losses were spurious (e.g., reordering). This feature
>> unconditionally lowers a reverted cwnd even though nothing
>> was lost.
>>
>> By principle loss recovery module should not update cwnd. Further
>> pacing is much more effective to reduce burst. Hence this patch
>> removes the cwnd moderation feature.
>>
>> Signed-off-by: Matt Mathis <mattmathis@google.com>
>> Signed-off-by: Neal Cardwell <ncardwell@google.com>
>> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
>
> I have a concern that this might break Linux builtin protection
> against hostile receiver sending bogus ACK's. Remember Linux is
> different than NewReno. You are changing something that has existed for
> a long long time.
I suppose the bogus ACKs are ACKs acking future but in-flight data
packets. The most bogus ACK would ack at most SND.NXT otherwise it
will be filtered early in tcp_ack(). Then cwnd_moderation() will pull
cwnd down to inflight + maxburst = 0 + 3 = 3. But immediately
afterward tcp_cwnd_reduction() will over-write cwnd = inflight +
sndcnt =~ 0 + newly_acked_sacked.
w/o pacing, such a bogus ACK can at most induce a burst of a window
(minus 3 dupacks). Restart after (short) idle or receiving stretched
ACKs can induce the same degree of behavior. More importantly the cwnd
moderation is already a NOP b/c cwnd is over-written by the PRR,
regardless of this patch. If the receiver's intention is to speed up
recovery, he is risking reliability w/ future ACKs. if the sole
intention is network abuse then he unlikely would bother to trigger
recovery and congestion control reactions in the first place.
I will update the commit message regarding your concern. Thanks.
^ permalink raw reply
* Re: [RFC] Add netdev all_adj_list refcnt propagation to fix panic
From: David Miller @ 2016-03-30 20:15 UTC (permalink / raw)
To: acollins; +Cc: netdev, mschiffer
In-Reply-To: <20160330.160150.1290720758360796805.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 30 Mar 2016 16:01:50 -0400 (EDT)
> Veaceslav, please look into this.
Of course, his email now bounces.... :-/
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Eric Dumazet @ 2016-03-30 20:15 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: Jesse Brandeburg, Alexander Duyck, Alexander Duyck, Netdev,
intel-wired-lan, Jeff Kirsher
In-Reply-To: <20160330200959.GI27540@oracle.com>
On Wed, 2016-03-30 at 16:09 -0400, Sowmini Varadhan wrote:
> On (03/30/16 12:41), Jesse Brandeburg wrote:
> > This gets "Even Uglier", I've turned off all offloads at my receiver,
> > enabled calling skb_linearize on *all* frames, which works fine for
> > scp, but the receiver shows > MSS sized frames on the wire for
> > rds-stress traffic.
>
> fwiw, I was not able to reproduce this tx issue with iperf/netperf
> etc either (I tried various perumtations of bidir, req-resp etc). One
> difference between the rds-stress invocation and the other callers
> is that this comes down via tcp_sendpage(), I dont know if there
> is something in the sendpage path that i40e does not anticipate.
You might try netperf -t TCP_SENDFILE -- -m 150
to let netperf use sendfile() on small frags.
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Sowmini Varadhan @ 2016-03-30 20:09 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Alexander Duyck, Alexander Duyck, Netdev, intel-wired-lan,
Jeff Kirsher
In-Reply-To: <20160330124135.000054c6@unknown>
On (03/30/16 12:41), Jesse Brandeburg wrote:
> This gets "Even Uglier", I've turned off all offloads at my receiver,
> enabled calling skb_linearize on *all* frames, which works fine for
> scp, but the receiver shows > MSS sized frames on the wire for
> rds-stress traffic.
fwiw, I was not able to reproduce this tx issue with iperf/netperf
etc either (I tried various perumtations of bidir, req-resp etc). One
difference between the rds-stress invocation and the other callers
is that this comes down via tcp_sendpage(), I dont know if there
is something in the sendpage path that i40e does not anticipate.
Other drivers (ixgbe etc) work fine, so my hunch would be that this
is specific to i40e (and not a skb_linearize bug) but I could be
wrong.
--Sowmini
^ permalink raw reply
* Re: [net PATCH v2] gro: Allow tunnel stacking in the case of FOU/GUE
From: David Miller @ 2016-03-30 20:03 UTC (permalink / raw)
To: aduyck; +Cc: jesse, netdev, alexander.duyck, tom
In-Reply-To: <20160329215226.12478.3696.stgit@localhost.localdomain>
From: Alexander Duyck <aduyck@mirantis.com>
Date: Tue, 29 Mar 2016 14:55:22 -0700
> This patch should fix the issues seen with a recent fix to prevent
> tunnel-in-tunnel frames from being generated with GRO. The fix itself is
> correct for now as long as we do not add any devices that support
> NETIF_F_GSO_GRE_CSUM. When such a device is added it could have the
> potential to mess things up due to the fact that the outer transport header
> points to the outer UDP header and not the GRE header as would be expected.
>
> Fixes: fac8e0f579695 ("tunnels: Don't apply GRO to multiple layers of encapsulation.")
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
> ---
>
> v2: Dropped switch statements per suggestion of Tom Herbert.
Applied, thanks Alex.
^ permalink raw reply
* Re: [RFC] Add netdev all_adj_list refcnt propagation to fix panic
From: David Miller @ 2016-03-30 20:01 UTC (permalink / raw)
To: acollins; +Cc: netdev, mschiffer, vfalico
In-Reply-To: <1459272303-8851-1-git-send-email-acollins@cradlepoint.com>
From: Andrew Collins <acollins@cradlepoint.com>
Date: Tue, 29 Mar 2016 11:25:03 -0600
> This is an RFC patch to fix a relatively easily reproducible kernel
> panic related to the all_adj_list handling for netdevs in recent kernels.
>
> This is more to generate discussion than anything else. I don't
> particularly like this approach, I'm hoping someone has a better idea.
>
> The following sequence of commands will reproduce the issue:
>
> ip link add link eth0 name eth0.100 type vlan id 100
> ip link add link eth0 name eth0.200 type vlan id 200
> ip link add name testbr type bridge
> ip link set eth0.100 master testbr
> ip link set eth0.200 master testbr
> ip link add link testbr mac0 type macvlan
> ip link delete dev testbr
>
> This creates an upper/lower tree of (excuse the poor ASCII art):
>
> /---eth0.100-eth0
> mac0-testbr-
> \---eth0.200-eth0
>
> When testbr is deleted, the all_adj_lists are walked, and eth0 is deleted twice from
> the mac0 list. Unfortunately, during setup in __netdev_upper_dev_link, only one
> reference to eth0 is added, so this results in a panic.
>
> This change adds reference count propagation so things are handled properly.
>
> Matthias Schiffer reported a similar crash in batman-adv:
>
> https://github.com/freifunk-gluon/gluon/issues/680
> https://www.open-mesh.org/issues/247
>
> which this patch also seems to resolve.
Veaceslav, please look into this.
Thanks.
^ permalink raw reply
* Re: [PATCH] sctp: flush if we can't fit another DATA chunk
From: marcelo.leitner @ 2016-03-30 19:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nhorman, vyasevich, linux-sctp
In-Reply-To: <20160330.154622.1322506750240048120.davem@davemloft.net>
On Wed, Mar 30, 2016 at 03:46:22PM -0400, David Miller wrote:
> From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Date: Tue, 29 Mar 2016 10:41:25 -0300
>
> > There is no point in delaying the packet if we can't fit a single byte
> > of data on it anymore. So lets just reduce the threshold by the amount
> > that a data chunk with 4 bytes (rounding) would use.
> >
> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> > ---
> > net/sctp/output.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/sctp/output.c b/net/sctp/output.c
> > index 97745351d58c2fb32b9f9b57d61831d7724d83b2..c518569123ce42a8f21f80754756306c39875013 100644
> > --- a/net/sctp/output.c
> > +++ b/net/sctp/output.c
> > @@ -705,7 +705,8 @@ static sctp_xmit_t sctp_packet_can_append_data(struct sctp_packet *packet,
> > /* Check whether this chunk and all the rest of pending data will fit
> > * or delay in hopes of bundling a full sized packet.
> > */
> > - if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
> > + if (chunk->skb->len + q->out_qlen >
> > + maxsize - packet->overhead - sizeof(sctp_data_chunk_t) - 4)
>
> There is no maxsize in this function.
>
> You must generate and test your patches against my networking tree.
>
> Neil, how were you able to see where 'maxsize' is and how it's even
> calculated before determining that this change is correct?
>
> Please don't ACK patches you really didn't verify in any way at all,
> thanks. It's better to have no reviews than bad reviews, because ACKs
> are supposed to give me a reason to be more confident in the change.
>
> Marcelo, I'm ignoring the rest of your SCTP changes, you have to get
> your act together.
Argh, indeed. Bad decision here to split up the patchset. Sorry for that.
Marcelo
^ permalink raw reply
* Re: [PATCH] qed: initialize return rc to avoid returning garbage
From: David Miller @ 2016-03-30 19:48 UTC (permalink / raw)
To: colin.king
Cc: Yuval.Mintz, Ariel.Elior, everest-linux-l2, netdev, linux-kernel
In-Reply-To: <1459270850-16177-1-git-send-email-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 29 Mar 2016 18:00:50 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> in the case where qed_slowpath_irq_req is not called, rc is not
> assigned and so qed_int_igu_enable will return a garbage value.
> Fix this by initializing rc to 0.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks.
^ permalink raw reply
* Re: am335x: no multicast reception over VLAN
From: Peter Korsgaard @ 2016-03-30 19:47 UTC (permalink / raw)
To: Mugunthan V N
Cc: Yegor Yefremov, Grygorii Strashko, netdev,
linux-omap@vger.kernel.org, drivshin, ml
In-Reply-To: <56FC0431.5000106@ti.com>
>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
Hi,
> You had received these packets as tcpdump will enable promiscuous mode
> so that you receive all the packets from the wire.
FYI, you can use the -p option to tcpdump to not put the interface into
promiscuous mode.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [net-next] bond: set mac address only if necessary
From: David Miller @ 2016-03-30 19:47 UTC (permalink / raw)
To: zhangshengju; +Cc: j.vosburgh, vfalico, gospo, netdev
In-Reply-To: <1459264457-19000-1-git-send-email-zhangshengju@cmss.chinamobile.com>
From: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Date: Tue, 29 Mar 2016 15:14:17 +0000
> Bond device gets it's mac address from the first slave device, it's not
> necessary to set slave device's mac address to bond if equal.
>
> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
I don't think bond enslavement occurs often enough to justify this
optimization, sorry.
^ permalink raw reply
* Re: [PATCH] sctp: flush if we can't fit another DATA chunk
From: David Miller @ 2016-03-30 19:46 UTC (permalink / raw)
To: marcelo.leitner; +Cc: netdev, nhorman, vyasevich, linux-sctp
In-Reply-To: <1459258885-21502-1-git-send-email-marcelo.leitner@gmail.com>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Tue, 29 Mar 2016 10:41:25 -0300
> There is no point in delaying the packet if we can't fit a single byte
> of data on it anymore. So lets just reduce the threshold by the amount
> that a data chunk with 4 bytes (rounding) would use.
>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/output.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index 97745351d58c2fb32b9f9b57d61831d7724d83b2..c518569123ce42a8f21f80754756306c39875013 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -705,7 +705,8 @@ static sctp_xmit_t sctp_packet_can_append_data(struct sctp_packet *packet,
> /* Check whether this chunk and all the rest of pending data will fit
> * or delay in hopes of bundling a full sized packet.
> */
> - if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
> + if (chunk->skb->len + q->out_qlen >
> + maxsize - packet->overhead - sizeof(sctp_data_chunk_t) - 4)
There is no maxsize in this function.
You must generate and test your patches against my networking tree.
Neil, how were you able to see where 'maxsize' is and how it's even
calculated before determining that this change is correct?
Please don't ACK patches you really didn't verify in any way at all,
thanks. It's better to have no reviews than bad reviews, because ACKs
are supposed to give me a reason to be more confident in the change.
Marcelo, I'm ignoring the rest of your SCTP changes, you have to get
your act together.
^ permalink raw reply
* Re: [PATCH-RFC] drivers: net: ethernet: intel: e1000e: fix ethtool autoneg off for fiber
From: Jeff Kirsher @ 2016-03-30 19:44 UTC (permalink / raw)
To: Daniel Walker, dima.ruinskiy
Cc: Steve Shih, danielwa, xe-kernel, intel-wired-lan, netdev
In-Reply-To: <56FC2A62.6040206@cisco.com>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Wed, 2016-03-30 at 12:34 -0700, Daniel Walker wrote:
>
> So Intel maintainers (Jeff, Jesse, Shannon, Carolyn, Don, Bruce, and
> John)
>
> I'm assuming no comments means this patch is acceptable , and I will
> resubmit it without the RFC. Is that acceptable ?
I personally do not see an issue with the patch, go ahead and submit it
as a non-RFC and I will make sure that the e1000e maintainer (Dima
Ruinskly) reviews it.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] sctp: really allow using GFP_KERNEL on sctp_packet_transmit
From: David Miller @ 2016-03-30 19:42 UTC (permalink / raw)
To: marcelo.leitner; +Cc: netdev, nhorman, vyasevich, linux-sctp
In-Reply-To: <1459258863-21351-1-git-send-email-marcelo.leitner@gmail.com>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Tue, 29 Mar 2016 10:41:03 -0300
> Somehow my patch for commit cea8768f333e ("sctp: allow
> sctp_transmit_packet and others to use gfp") missed two important
> chunks, which are now added.
>
> Fixes: cea8768f333e ("sctp: allow sctp_transmit_packet and others to use gfp")
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Applied.
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Jesse Brandeburg @ 2016-03-30 19:41 UTC (permalink / raw)
To: Alexander Duyck
Cc: Sowmini Varadhan, Alexander Duyck, Netdev, intel-wired-lan,
Jeff Kirsher, jesse.brandeburg
In-Reply-To: <CAKgT0Ufb-_X-DD2jYkVJQwLZ-JBfWD2Biuhi6YaxWBeNy9K2fQ@mail.gmail.com>
On Wed, 30 Mar 2016 10:35:55 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> On Wed, Mar 30, 2016 at 10:20 AM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
> > On (03/30/16 10:12), Alexander Duyck wrote:
> >> Yeah. The patch was sort of a knee-jerk reaction to being told that
> >> the patch referenced caused a regression. From what I can tell that
> >> is not the case as I am also seeing the Tx hangs when I run the test
> >> with the frames being linearized.
> >
> > I'm not sure how important of a subtlety this is, but the actual
> > console log after the patch is the following:
> >
> > i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> > i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> > i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> > i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> > i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> >
> > Comparing with what I'd pasted in the sourceforge thread earlier,
> > I see that it does not say "Hung Tx queue etc." any more, though
> > it still resets.
> >
> > Not sure if that changed info is significant?
>
> It might be. Right now I am chasing down the Tx driver issue as that
> I what I am reproducing in my environment as well.
This gets "Even Uglier", I've turned off all offloads at my receiver,
enabled calling skb_linearize on *all* frames, which works fine for
scp, but the receiver shows > MSS sized frames on the wire for
rds-stress traffic.
This implies to me we have some issue with skb_linearize, possibly in
how the stack linearizes the data, or how the driver interprets the
linearized packets (which should always work)
Wheee......
^ permalink raw reply
* Re: [PATCH] bridge: Allow set bridge ageing time when switchdev disabled
From: David Miller @ 2016-03-30 19:40 UTC (permalink / raw)
To: yanhaishuang; +Cc: netdev, bridge, linux-kernel
In-Reply-To: <1459248488-25621-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Tue, 29 Mar 2016 18:48:08 +0800
> When NET_SWITCHDEV=n, switchdev_port_attr_set will return -EOPNOTSUPP,
> we should ignore this error code and continue to set the ageing time.
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied and queued up for -stable, thanks.
> @@ -582,7 +582,7 @@ int br_set_ageing_time(struct net_bridge *br, u32 ageing_time)
> int err;
>
> err = switchdev_port_attr_set(br->dev, &attr);
> - if (err)
> + if (err && err != -EOPNOTSUPP)
> return err;
>
> br->ageing_time = t;
This is at least the 5th time I've had to apply a bug fix exactly like
this one.
If this doesn't convince everyone that this whole -EOPNOTSUPP
mechanism is extremely error prone, I don't know what will.
There should be only one or two strictly controlled locations that
reinterpret the return value from all of these routines that have this
special way of signalling lack of switchdev support via -EOPNOTSUPP.
It can't be spread all over the place like this, it simply does NOT work.
^ permalink raw reply
* Re: [net-next] bond: output message before setting slave to inactive
From: David Miller @ 2016-03-30 19:37 UTC (permalink / raw)
To: zhangshengju; +Cc: j.vosburgh, vfalico, gospo, netdev
In-Reply-To: <1459233177-6394-1-git-send-email-zhangshengju@cmss.chinamobile.com>
From: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Date: Tue, 29 Mar 2016 06:32:57 +0000
> This patch moves output message before setting slave to inactive, this will
> print the correct status of slave device.
>
> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
I think the message is in the appropriate spot wrt. state, so I will not
apply this, thanks.
^ permalink raw reply
* Re: [PATCH-RFC] drivers: net: ethernet: intel: e1000e: fix ethtool autoneg off for fiber
From: Daniel Walker @ 2016-03-30 19:34 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg, Shannon Nelson, Carolyn Wyborny,
Don Skidmore, Bruce Allan, John Ronciak, Mitch Williams
Cc: Steve Shih, danielwa, xe-kernel, intel-wired-lan, netdev,
linux-kernel
In-Reply-To: <1458943126-32258-1-git-send-email-danielwa@cisco.com>
So Intel maintainers (Jeff, Jesse, Shannon, Carolyn, Don, Bruce, and John)
I'm assuming no comments means this patch is acceptable , and I will
resubmit it without the RFC. Is that acceptable ?
On 03/25/2016 02:58 PM, Daniel Walker wrote:
> From: Steve Shih <sshih@cisco.com>
>
> This patch fixes the issues for disabling auto-negotiation and forcing
> speed and duplex settings for the fiber media.
>
> For fiber media, e1000_get_settings should return ETH_TP_MDI_INVALID for
> eth_tp_mdix_ctrl instead of ETH_TP_MDI_AUTO so subsequent e1000_set_settings
> call would not fail with -EOPNOTSUPP.
>
> e1000_set_spd_dplx should not automatically turn autoneg back on for forced
> 1000 Mbps full duplex settings.
>
> Cc: danielwa@fifo99.com
> Cc: xe-kernel@external.cisco.com
> Signed-off-by: Steve Shih <sshih@cisco.com>
> ---
> drivers/net/ethernet/intel/e1000e/ethtool.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c b/drivers/net/ethernet/intel/e1000e/ethtool.c
> index 6cab1f3..cd03dcd 100644
> --- a/drivers/net/ethernet/intel/e1000e/ethtool.c
> +++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
> @@ -201,6 +201,9 @@ static int e1000_get_settings(struct net_device *netdev,
> else
> ecmd->eth_tp_mdix_ctrl = hw->phy.mdix;
>
> + if (hw->phy.media_type != e1000_media_type_copper)
> + ecmd->eth_tp_mdix_ctrl = ETH_TP_MDI_INVALID;
> +
> return 0;
> }
>
> @@ -236,8 +239,7 @@ static int e1000_set_spd_dplx(struct e1000_adapter *adapter, u32 spd, u8 dplx)
> mac->forced_speed_duplex = ADVERTISE_100_FULL;
> break;
> case SPEED_1000 + DUPLEX_FULL:
> - mac->autoneg = 1;
> - adapter->hw.phy.autoneg_advertised = ADVERTISE_1000_FULL;
> + mac->forced_speed_duplex = ADVERTISE_1000_FULL;
> break;
> case SPEED_1000 + DUPLEX_HALF: /* not supported */
> default:
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Jesse Brandeburg @ 2016-03-30 18:38 UTC (permalink / raw)
To: Alexander Duyck
Cc: Sowmini Varadhan, Alexander Duyck, Netdev, intel-wired-lan,
Jeff Kirsher, jesse.brandeburg
In-Reply-To: <CAKgT0UdTgaeamyLetGPK0mqMNS-80BTc8t-WdSGJuuLDfz4JOg@mail.gmail.com>
On Wed, 30 Mar 2016 10:12:51 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> On Wed, Mar 30, 2016 at 10:00 AM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
> > On (03/29/16 23:44), Alexander Duyck wrote:
> >> This patch has been sanity checked only. I cannot yet guarantee it
> >> resolves the original issue that was reported. I'll try to get a
> >> reproduction environment setup tomorrow but I don't know how long that
> >> should take.
> >
> > I tried this out with rds-stress on my test-pair, unfortunately, I
> > still see the Tx hang.
> >
> > Setting up the test is quite easy- for reference, the instructions
> > are here:
> > https://sourceforge.net/p/e1000/mailman/message/34936766/
>
> Yeah. The patch was sort of a knee-jerk reaction to being told that
> the patch referenced caused a regression. From what I can tell that
Thanks for working so hard on the patch Alex, I need to apologize, as
the original test appears to fail as well with 1.3.46-k (a previous
driver to your patch) and I thought we had already tested that, but I
was wrong.
This is not a regression, but likely just an undetected "bug" that we
need to work out.
> is not the case as I am also seeing the Tx hangs when I run the test
> with the frames being linearized.
That doesn't make much sense unless it is something about how we are
setting up the offload. I troubleshoot by disabling the PFR from the
MDD code, then disabling tx timeout via debugfs, and using debugfs to
dump the descriptor ring after the MDD event fires.
> I'll do some research this morning to see if I can find a root cause.
> Unfortunately the malicious driver detection isn't very well
> documented so I can't be certain what is causing it to be triggered.
I'm still looking at this too and appreciate the help.
^ permalink raw reply
* Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages
From: Fabio Estevam @ 2016-03-30 18:37 UTC (permalink / raw)
To: Greg Ungerer; +Cc: Troy Kisky, netdev@vger.kernel.org
In-Reply-To: <56FB46EA.7050401@uclinux.org>
Hi Greg,
On Wed, Mar 30, 2016 at 12:24 AM, Greg Ungerer <gerg@uclinux.org> wrote:
> Hi Troy,
>
> Commit 55cd48c8 ('net: fec: stop the "rcv is not +last, " error
> messages') adds a write to a register that is not present in all
> implementations of the FEC hardware module. None of the ColdFire
> SoC parts with the FEC module have the FTRL (0x1b0) register.
>
> Does this need a quirk flag to key access to this register of?
> Or can you piggyback on the FEC_QUIRK_HAS_RACC flag?
Would the change below work on Coldfire?
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -943,8 +943,8 @@ fec_restart(struct net_device *ndev)
else
val &= ~FEC_RACC_OPTIONS;
writel(val, fep->hwp + FEC_RACC);
- }
writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL);
+ }
#endif
/*
^ permalink raw reply
* Re: [PATCH RFC net-next] net: core: Pass XPS select queue decision to skb_tx_hash
From: Saeed Mahameed @ 2016-03-30 18:30 UTC (permalink / raw)
To: John Fastabend
Cc: Saeed Mahameed, Linux Netdev List, Eric Dumazet, Tom Herbert,
Jiri Pirko, David S. Miller, John Fastabend
In-Reply-To: <56FC0723.4040003@gmail.com>
On Wed, Mar 30, 2016 at 8:04 PM, John Fastabend
<john.fastabend@gmail.com> wrote:
>
> OK, so let me see if I get this right now. This was the precedence
> before the patch in the normal no select queue case,
>
> (1) socket mapping sk_tx_queue_mapping iff !ooo_okay
> (2) xps
> (3) skb->queue_mapping
> (4) qoffset/qcount (hash over tc queues)
> (5) hash over num_tx_queues
>
> With this patch the precedence is a bit changed because
> skb_tx_hash is always called.
>
> (1) socket mapping sk_tx_queue_mapping iff !ooo_okay
> (2) skb->queue_mapping
> (3) qoffset/qcount
> (hash over tc queues if xps choice is > qcount)
> (4) xps
> (5) hash over num_tx_queues
>
> Sound right? Nice thing about this with correct configuration
> of tc with qcount = xps_queues it sort of works as at least
Yes !
for qcount = xps_queues which almost all drivers default
configurations goes this way, it works like charm, xps selects the
exact TC TX queue at the correct offset without any need for further
SKB hashing.
and even if by mistake XPS was also configured on TC TX queue then
this patch will detect that the xps hash is out of this TC
offset/qcount range and will re-hash. But i don't see why would user
or driver do such strange configuration.
> I expect it to. I think the question is are people OK with
> letting skb->queue_mapping take precedence. I am at least
> because it makes the skb edit queue_mapping action from tc
> easier to use.
>
skb->queue_mapping toke precedence also before this patch, the only
thing this patch came to change is how to compute the txq when
skb->queue_mapping is not present, so we don't need to worry about
this.
> And just a comment on the code why not just move get_xps_queue
> into skb_tx_hash at this point if its always being called as the
> "hint". Then we avoid calling it in the case queue_mapping is
> set.
>
Very good point, the only place that calls skb_tx_hash(dev, skb) other
than __netdev_pick_tx is mlx4 driver and they did it there just
because they wanted to bypass XPS configuration if TC QoS is
configured, with this fix we don't have to bypass XPS at all for when
TC is configured.
I will change it.
^ permalink raw reply
* Re: [PATCH] stmmac: Fix phy without MDIO subnode
From: Robert Gadsdon @ 2016-03-30 18:22 UTC (permalink / raw)
To: Giuseppe CAVALLARO, John Keeping; +Cc: Gabriel Fernandez, netdev, linux-kernel
In-Reply-To: <56F4F9F6.8070103@st.com>
I have applied this to my Rock2 - Kernel 4.6-rc1 - and eth0 is present,
now, but no network traffic gets through:
To rock2:
$ ping rgrock2
PING rgrock2 (192.168.0.xx) 56(84) bytes of data.
^C
--- rgrock2 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms
>From rock2:
# ping 192.168.0.x
PING 192.168.0.x (192.168.0.2) 56(84) bytes of data.
>From 192.168.0.xx icmp_seq=1 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=2 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=3 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=4 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=5 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=6 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=7 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=8 Destination Host Unreachable
--- 192.168.0.x ping statistics ---
9 packets transmitted, 0 received, +8 errors, 100% packet loss, time 8001ms
Everything worked OK with kernel 4.5-rc7, and with 4.5 Final with the
-rc7 versions of stmmac_platform.c and stmmac_mdio.c substituted..
Robert Gadsdon. March 30, 2016
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Alexander Duyck @ 2016-03-30 17:35 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: Alexander Duyck, Netdev, intel-wired-lan, Brandeburg, Jesse,
Jeff Kirsher
In-Reply-To: <20160330172001.GD27540@oracle.com>
On Wed, Mar 30, 2016 at 10:20 AM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> On (03/30/16 10:12), Alexander Duyck wrote:
>> Yeah. The patch was sort of a knee-jerk reaction to being told that
>> the patch referenced caused a regression. From what I can tell that
>> is not the case as I am also seeing the Tx hangs when I run the test
>> with the frames being linearized.
>
> I'm not sure how important of a subtlety this is, but the actual
> console log after the patch is the following:
>
> i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> i40e 0000:82:00.0: TX driver issue detected, PF reset issued
>
> Comparing with what I'd pasted in the sourceforge thread earlier,
> I see that it does not say "Hung Tx queue etc." any more, though
> it still resets.
>
> Not sure if that changed info is significant?
It might be. Right now I am chasing down the Tx driver issue as that
I what I am reproducing in my environment as well.
>From what I can tell by enabling msglvl tx_err it is reporting MDD
event 0x2. Unfortunately the documentation doesn't say what that is
so I am checking a few different possibilities.
- Alex
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Sowmini Varadhan @ 2016-03-30 17:20 UTC (permalink / raw)
To: Alexander Duyck
Cc: Alexander Duyck, Netdev, intel-wired-lan, Brandeburg, Jesse,
Jeff Kirsher
In-Reply-To: <CAKgT0UdTgaeamyLetGPK0mqMNS-80BTc8t-WdSGJuuLDfz4JOg@mail.gmail.com>
On (03/30/16 10:12), Alexander Duyck wrote:
> Yeah. The patch was sort of a knee-jerk reaction to being told that
> the patch referenced caused a regression. From what I can tell that
> is not the case as I am also seeing the Tx hangs when I run the test
> with the frames being linearized.
I'm not sure how important of a subtlety this is, but the actual
console log after the patch is the following:
i40e 0000:82:00.0: TX driver issue detected, PF reset issued
i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
i40e 0000:82:00.0: TX driver issue detected, PF reset issued
i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
i40e 0000:82:00.0: TX driver issue detected, PF reset issued
Comparing with what I'd pasted in the sourceforge thread earlier,
I see that it does not say "Hung Tx queue etc." any more, though
it still resets.
Not sure if that changed info is significant?
--Sowmini
^ 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