* Re: [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned
From: Sarah Sharp @ 2014-01-30 21:55 UTC (permalink / raw)
To: Alan Stern
Cc: David Laight, linux-usb@vger.kernel.org, netdev@vger.kernel.org,
Greg Kroah-Hartman, David Miller, Dan Williams, Nyman, Mathias,
Mark Lord, Freddy Xin
In-Reply-To: <Pine.LNX.4.44L0.1401301630340.31548-100000@netrider.rowland.org>
On Thu, Jan 30, 2014 at 04:43:54PM -0500, Alan Stern wrote:
> On Thu, 30 Jan 2014, Sarah Sharp wrote:
>
> > It should not matter what alignment or length of scatter-gather list the
> > upper layers pass the xHCI driver, it should just work. I want to do
> > this fix right, by changing the fundamental way we queue TRBs to the
> > rings to fit the TD rules. We should break each TD into fragment-sized
> > chunks, and add a link TRB in the middle of a segment where necessary.
>
> That's a good plan. However _some_ restriction will turn out to be
> necessary.
>
> For example, what will you do if a driver submits an SG list containing
> 300 elements, each 3 bytes long? That's too many to fit in a single
> ring segment, but it's smaller than a TD fragment -- it's even smaller
> than maxpacket -- so there's no place to split it. (Not that I think
> drivers _will_ submit requests like this; this is just to demonstrate
> the point.)
>
> It ought to be acceptable to require, for example, that an SG URB
> contain no more than (say) 100 elements that are smaller than 512
> bytes.
At that point, the xHCI driver or USB core should probably use a bounce
buffer. It feels like we should attempt to push down scatter-gather
lists as far down in the stack as possible, so the upper layers don't
have to care what alignment, length, or random 64KB boundary splits we
need.
> ehci-hcd gets along okay with the restriction that each SG element
> except the last has to be a multiple of the maxpacket size. xhci-hcd
> can relax this quite a lot, but not all the way.
What does the EHCI driver do when it receives a SG list from the USB
networking layer that violates this restriction?
Sarah Sharp
^ permalink raw reply
* Re: [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned
From: Bjørn Mork @ 2014-01-30 22:05 UTC (permalink / raw)
To: Sarah Sharp
Cc: Alan Stern, David Laight, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Greg Kroah-Hartman, David Miller,
Dan Williams, Nyman, Mathias, Mark Lord, Freddy Xin
In-Reply-To: <20140130215523.GC14228@xanatos>
Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> On Thu, Jan 30, 2014 at 04:43:54PM -0500, Alan Stern wrote:
>
>> ehci-hcd gets along okay with the restriction that each SG element
>> except the last has to be a multiple of the maxpacket size. xhci-hcd
>> can relax this quite a lot, but not all the way.
>
> What does the EHCI driver do when it receives a SG list from the USB
> networking layer that violates this restriction?
The USB networking layer won't use SG with the EHCI driver.
Commit bcc48f1a7a0d4 introduced no_sg_constraint so that usbnet could
enable SG only for host controllers with no such restrictions. I.e.
currently for xHCI only.
Bjørn
^ permalink raw reply
* Re: [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned
From: Alan Stern @ 2014-01-30 22:07 UTC (permalink / raw)
To: Sarah Sharp
Cc: David Laight, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Greg Kroah-Hartman, David Miller, Dan Williams, Nyman, Mathias,
Mark Lord, Freddy Xin
In-Reply-To: <20140130215523.GC14228@xanatos>
On Thu, 30 Jan 2014, Sarah Sharp wrote:
> > That's a good plan. However _some_ restriction will turn out to be
> > necessary.
> >
> > For example, what will you do if a driver submits an SG list containing
> > 300 elements, each 3 bytes long? That's too many to fit in a single
> > ring segment, but it's smaller than a TD fragment -- it's even smaller
> > than maxpacket -- so there's no place to split it. (Not that I think
> > drivers _will_ submit requests like this; this is just to demonstrate
> > the point.)
> >
> > It ought to be acceptable to require, for example, that an SG URB
> > contain no more than (say) 100 elements that are smaller than 512
> > bytes.
>
> At that point, the xHCI driver or USB core should probably use a bounce
> buffer. It feels like we should attempt to push down scatter-gather
> lists as far down in the stack as possible, so the upper layers don't
> have to care what alignment, length, or random 64KB boundary splits we
> need.
Okay. That should be doable, if awkward.
> > ehci-hcd gets along okay with the restriction that each SG element
> > except the last has to be a multiple of the maxpacket size. xhci-hcd
> > can relax this quite a lot, but not all the way.
>
> What does the EHCI driver do when it receives a SG list from the USB
> networking layer that violates this restriction?
It never receives such lists. usb_submit_urb() returns -EINVAL before
the request gets sent to ehci-hcd.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] [BUG FIXES - 3.10.27] sit: More backports
From: Steven Rostedt @ 2014-01-30 22:10 UTC (permalink / raw)
To: nicolas.dichtel
Cc: linux-kernel, netdev, stable, Clark Williams,
Luis Claudio R. Goncalves, John Kacur, Willem de Bruijn
In-Reply-To: <52EA56E1.40507@6wind.com>
On Thu, 30 Jan 2014 14:42:57 +0100
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> > I'll let you know when these are finished.
> Thank you for testing.
Our short tests that were crashing have all now passed :-) with your
patches applied.
We are now running our full tier tests on the code, but I don't think
we need to wait. Please add my tags to your patches, and hopefully we
can get David to give us a new blessing on your patch set.
David and Greg,
You can ignore my patches as it seems that Nicolas's patches solve the
issues we have been seeing on 3.10.
Nicolas,
Thanks for all your effort in helping us out here :-)
Reported-by: Steven Rostedt <srostedt@redhat.com>
Tested-by: Steven Rostedt <srostedt@redhat.com> (and our entire MRG team)
Tested-by: "Luis Claudio R. Goncalves" <lgoncalv@redhat.com>
Tested-by: John Kacur <jkacur@redhat.com>
I don't usually give my Red Hat email for things like this, but as this
was found and tested with the Red Hat infrastructure, with the help
from Luis and John (and others), I would like to give them credit too.
-- Steve
^ permalink raw reply
* Re: [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned
From: Sarah Sharp @ 2014-01-30 22:15 UTC (permalink / raw)
To: Bjørn Mork
Cc: David Laight, linux-usb@vger.kernel.org, netdev@vger.kernel.org,
Greg Kroah-Hartman, David Miller, Dan Williams, Nyman, Mathias,
Mark Lord, Alan Stern, Freddy Xin, Ming Lei
In-Reply-To: <87iot1qgv6.fsf@nemi.mork.no>
On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
> FWIW, the plan looks fine to me. Just adding a couple of hints to
> simplify the implementation.
>
> Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
>
> > Let's do this fix the right way, instead of wall papering over the
> > issue. Here's what we should do:
> >
> > 1. Disable scatter-gather for the ax88179_178a driver when it's under an
> > xHCI host.
>
> No need to make this conditional. SG is only enabled in the
> ax88179_178a driver if udev->bus->no_sg_constraint is true, so it
> applies only to xHCI hosts in the first place.
Ah, so you're suggesting just reverting commit
3804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a: enable
tso if usb host supports sg dma"?
> > 2. Revert the following commits:
> > f2d9b991c549 xhci: Set scatter-gather limit to avoid failed block writes.
> > d6c9ea9069af xhci: Avoid infinite loop when sg urb requires too many trbs
> > 35773dac5f86 usb: xhci: Link TRB must not occur within a USB payload burst
> >
> > 3. Dan and Mathias can work together to come up with an overall plan to
> > change the xHCI driver architecture to be fully compliant with the TD
> > fragment rules. That can be done over the next few kernel releases.
> >
> > The end result is that we don't destabilize storage or break userspace
> > USB drivers, we don't break people's xHCI host controllers,
> > the ax88179_178a USB ethernet devices still work under xHCI (a bit with
> > worse performance), and other USB ethernet devices still get the
> > performance improvement introduced in 3.12.
>
> No other usbnet drivers has enabled SG... Which is why you have only
> seen this problem with the ax88179_178a devices. So there is no
> performance improvement to keep.
I see.
Sarah Sharp
^ permalink raw reply
* Re: Help testing for USB ethernet/xHCI regression
From: Mark Lord @ 2014-01-30 22:20 UTC (permalink / raw)
To: Sarah Sharp
Cc: Paul Zimmerman, David Laight, renevant@internode.on.net,
linux-usb@vger.kernel.org, Greg Kroah-Hartman,
netdev@vger.kernel.org
In-Reply-To: <20140130214133.GB14228@xanatos>
On 14-01-30 04:41 PM, Sarah Sharp wrote:
>
> Mark and David, can you pull the 3.13-td-changes-reverted branch again,
> and see if the latest patch fixes your issue? It disables scatter
> gather for the ax88179_178a device, but only when it's operating at USB
> 3.0 speeds.
As expected, this works just fine.
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
* [RFC PATCH] net: rfkill: move poll work to power efficient workqueue
From: Zoran Markovic @ 2014-01-30 22:43 UTC (permalink / raw)
To: linux-kernel
Cc: linux-wireless, netdev, Shaibal Dutta, Johannes Berg,
John W. Linville, David S. Miller, Zoran Markovic
From: Shaibal Dutta <shaibal.dutta@broadcom.com>
This patch moves the rfkill poll_work to the power efficient workqueue.
This work does not have to be bound to the CPU that scheduled it, hence
the selection of CPU that executes it would be left to the scheduler.
Net result is that CPU idle times would be extended, resulting in power
savings.
This behaviour is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com>
[zoran.markovic@linaro.org: Rebased to latest kernel, added commit message.
Fixed workqueue selection after suspend/resume cycle.]
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
---
net/rfkill/core.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index ed7e0b4..b3b16c0 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -789,7 +789,8 @@ void rfkill_resume_polling(struct rfkill *rfkill)
if (!rfkill->ops->poll)
return;
- schedule_work(&rfkill->poll_work.work);
+ queue_delayed_work(system_power_efficient_wq,
+ &rfkill->poll_work, 0);
}
EXPORT_SYMBOL(rfkill_resume_polling);
@@ -894,7 +895,8 @@ static void rfkill_poll(struct work_struct *work)
*/
rfkill->ops->poll(rfkill, rfkill->data);
- schedule_delayed_work(&rfkill->poll_work,
+ queue_delayed_work(system_power_efficient_wq,
+ &rfkill->poll_work,
round_jiffies_relative(POLL_INTERVAL));
}
@@ -958,7 +960,8 @@ int __must_check rfkill_register(struct rfkill *rfkill)
INIT_WORK(&rfkill->sync_work, rfkill_sync_work);
if (rfkill->ops->poll)
- schedule_delayed_work(&rfkill->poll_work,
+ queue_delayed_work(system_power_efficient_wq,
+ &rfkill->poll_work,
round_jiffies_relative(POLL_INTERVAL));
if (!rfkill->persistent || rfkill_epo_lock_active) {
--
1.7.9.5
^ permalink raw reply related
* Re: IGMP joins come from the wrong SA/interface
From: Hannes Frederic Sowa @ 2014-01-30 22:44 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: netdev
In-Reply-To: <20140130181229.GA32245@sesse.net>
On Thu, Jan 30, 2014 at 07:12:29PM +0100, Steinar H. Gunderson wrote:
> On Thu, Jan 30, 2014 at 04:08:11PM -0200, Flavio Leitner wrote:
> > No special multicast route, so it should go out on em1/default route.
>
> Well, that's not really relevant for my bug then, is it? My problem is that
> it goes out on the default unicast route, whereas it shouldn't.
Hmm, it looks to me that Flavio showed that it should actually work
correctly.
> > Maybe your application is using wrong values to IP_MULTICAST_IF?
> > strace and /proc/net/igmp as suggested might help you find out.
>
> This goes for at least vlc+mplayer+xbmc. I don't think they would all be
> buggy in the same way? (Actually I don't think any of them set
> IP_MULTICAST_IF.)
The routing lookup is done at IP_ADD_MEMBERSHIP time. I really wonder why you
have routed the 239.0.0.0/8 range to eth0.11. It seems to me that the kernel
does what you told it to do. ;)
multicast flag on ip route is just used for multicast forwarding and does not
matter for local multicast. Also if we find unicast route first (more
specific) kernel does not do backtracking if destination is in multicast
scope.
Greetings,
Hannes
^ permalink raw reply
* [RFC PATCH] net: wireless: move regulatory timeout work to power efficient workqueue
From: Zoran Markovic @ 2014-01-30 23:08 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Shaibal Dutta, Johannes Berg,
John W. Linville, David S. Miller, Zoran Markovic
From: Shaibal Dutta <shaibal.dutta-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
For better use of CPU idle time, allow the scheduler to select the CPU
on which the timeout work of regulatory settings would be executed.
This extends CPU idle residency time and saves power.
This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
Cc: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Signed-off-by: Shaibal Dutta <shaibal.dutta-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
[zoran.markovic-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org: Rebased to latest kernel. Added commit message.]
Signed-off-by: Zoran Markovic <zoran.markovic-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
net/wireless/reg.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 9b897fc..6e21011 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1703,7 +1703,8 @@ static void reg_process_hint(struct regulatory_request *reg_request)
if (treatment == REG_REQ_OK ||
treatment == REG_REQ_ALREADY_SET)
return;
- schedule_delayed_work(®_timeout, msecs_to_jiffies(3142));
+ queue_delayed_work(system_power_efficient_wq,
+ ®_timeout, msecs_to_jiffies(3142));
return;
case NL80211_REGDOM_SET_BY_DRIVER:
treatment = reg_process_hint_driver(wiphy, reg_request);
@@ -2294,7 +2295,8 @@ static int reg_set_rd_driver(const struct ieee80211_regdomain *rd,
request_wiphy = wiphy_idx_to_wiphy(driver_request->wiphy_idx);
if (!request_wiphy) {
- schedule_delayed_work(®_timeout, 0);
+ queue_delayed_work(system_power_efficient_wq,
+ ®_timeout, 0);
return -ENODEV;
}
@@ -2354,7 +2356,8 @@ static int reg_set_rd_country_ie(const struct ieee80211_regdomain *rd,
request_wiphy = wiphy_idx_to_wiphy(country_ie_request->wiphy_idx);
if (!request_wiphy) {
- schedule_delayed_work(®_timeout, 0);
+ queue_delayed_work(system_power_efficient_wq,
+ ®_timeout, 0);
return -ENODEV;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH stable 3.9+] can: add destructor for self generated skbs
From: Eric Dumazet @ 2014-01-30 23:10 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: David Miller, Andre Naujoks, Linux Netdev List,
linux-can@vger.kernel.org
In-Reply-To: <52EA1740.2010108@hartkopp.net>
On Thu, 2014-01-30 at 10:11 +0100, Oliver Hartkopp wrote:
> Self generated skbuffs in net/can/bcm.c are setting a skb->sk reference but
> no explicit destructor which is enforced since Linux 3.11 with commit
> 376c7311bdb6 (net: add a temporary sanity check in skb_orphan()).
>
> This patch adds some helper functions to make sure that a destructor is
> properly defined when a sock reference is assigned to a CAN related skb.
> To create an unshared skb owned by the original sock a common helper function
> has been introduced to replace open coded functions to create CAN echo skbs.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> Tested-by: Andre Naujoks <nautsch2@gmail.com>
>
> ---
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: Help testing for USB ethernet/xHCI regression
From: Sarah Sharp @ 2014-01-30 23:26 UTC (permalink / raw)
To: Mark Lord
Cc: Paul Zimmerman, David Laight,
renevant-CkBdp7X+a1oIQCUVoCVjmQ@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Greg Kroah-Hartman,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <52EAD038.5020409-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
On Thu, Jan 30, 2014 at 05:20:40PM -0500, Mark Lord wrote:
> On 14-01-30 04:41 PM, Sarah Sharp wrote:
> >
> > Mark and David, can you pull the 3.13-td-changes-reverted branch again,
> > and see if the latest patch fixes your issue? It disables scatter
> > gather for the ax88179_178a device, but only when it's operating at USB
> > 3.0 speeds.
>
> As expected, this works just fine.
Did it work when plugged into a USB 2.0 hub?
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ipv6: default route for link local address is not added while assigning a address
From: Hannes Frederic Sowa @ 2014-01-30 23:29 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: Sohny Thomas, netdev, linux-kernel, yoshfuji, davem, kumuda
In-Reply-To: <52E8DA37.7010208@6wind.com>
Sorry for replying so late...
On Wed, Jan 29, 2014 at 11:38:47AM +0100, Nicolas Dichtel wrote:
> Le 29/01/2014 07:41, Sohny Thomas a écrit :
> >Resending this on netdev mailing list:
> >Default route for link local address is configured automatically if
> >NETWORKING_IPV6=yes is in ifcfg-eth*.
> >When the route table for the interface is flushed and a new address is
> >added to
> >the same device with out removing linklocal addr, default route for link
> >local
> >address has to added by default.
> >
> >I have found the issue to be caused by this checkin
> >
> >http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/ipv6?id=62b54dd91567686a1cb118f76a72d5f4764a86dd
> >
> >
> >According to this change :
> >He removes adding a link local route if any other address is added ,
> >applicable
> >across all interfaces though there's mentioned only lo interface
> >So below patch fixes for other devices
> >
> >Signed-off-by: Sohny THomas <sohthoma@linux.vnet.ibm.com>
> Your email client has corrupted the patch, it cannot be applied.
> Please read Documentation/email-clients.txt
>
> About the patch, I still think that the flush is too agressive. Link local
> routes are marked as 'proto kernel', removing them without the link local
> address is wrong.
Actually I am not so sure, there is no defined semantic of flush. I would
be ok with all three solutions: leave it as is, always add link-local
address (it does not matter if we don't have a link-local address on
that interface, as a global scoped one is just fine enough) or make flush not
remove the link-local address (but this seems a bit too special cased for me).
Greetings,
Hannes
^ permalink raw reply
* [RFC PATCH] net: ipv4: move inetpeer garbage collector work to power efficient workqueue
From: Zoran Markovic @ 2014-01-30 23:40 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Shaibal Dutta, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Zoran Markovic
From: Shaibal Dutta <shaibal.dutta@broadcom.com>
Garbage collector work does not have to be bound to the CPU that scheduled
it. By moving work to the power-efficient workqueue, the selection of
CPU executing the work is left to the scheduler. This extends idle
residency times and conserves power.
This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com>
[zoran.markovic@linaro.org: Rebased to latest kernel version. Added
commit message.]
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
---
net/ipv4/inetpeer.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index 48f4244..87155aa 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -161,7 +161,8 @@ static void inetpeer_gc_worker(struct work_struct *work)
list_splice(&list, &gc_list);
spin_unlock_bh(&gc_lock);
- schedule_delayed_work(&gc_work, gc_delay);
+ queue_delayed_work(system_power_efficient_wq,
+ &gc_work, gc_delay);
}
/* Called from ip_output.c:ip_init */
@@ -576,7 +577,8 @@ static void inetpeer_inval_rcu(struct rcu_head *head)
list_add_tail(&p->gc_list, &gc_list);
spin_unlock_bh(&gc_lock);
- schedule_delayed_work(&gc_work, gc_delay);
+ queue_delayed_work(system_power_efficient_wq,
+ &gc_work, gc_delay);
}
void inetpeer_invalidate_tree(struct inet_peer_base *base)
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned
From: Ming Lei @ 2014-01-31 0:17 UTC (permalink / raw)
To: Sarah Sharp
Cc: Bjørn Mork, David Laight,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Greg Kroah-Hartman, David Miller, Dan Williams, Nyman, Mathias,
Mark Lord, Alan Stern, Freddy Xin
In-Reply-To: <20140130221511.GD14228@xanatos>
On Fri, Jan 31, 2014 at 6:15 AM, Sarah Sharp
<sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
>> FWIW, the plan looks fine to me. Just adding a couple of hints to
>> simplify the implementation.
>>
>> Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes:
>>
>> > Let's do this fix the right way, instead of wall papering over the
>> > issue. Here's what we should do:
>> >
>> > 1. Disable scatter-gather for the ax88179_178a driver when it's under an
>> > xHCI host.
>>
>> No need to make this conditional. SG is only enabled in the
>> ax88179_178a driver if udev->bus->no_sg_constraint is true, so it
>> applies only to xHCI hosts in the first place.
>
> Ah, so you're suggesting just reverting commit
> 3804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a: enable
> tso if usb host supports sg dma"?
If I understand the problem correctly, the current issue is that xhci driver
doesn't support the arbitrary dma length not well, but per XHCI spec, it
should be supported, right?
If the above is correct, reverting the commit isn't correct since there isn't
any issue about the commit, so I suggest to disable the flag in xhci
for the buggy devices, and it may be enabled again if the problem is fixed.
>
>> > 2. Revert the following commits:
>> > f2d9b991c549 xhci: Set scatter-gather limit to avoid failed block writes.
>> > d6c9ea9069af xhci: Avoid infinite loop when sg urb requires too many trbs
>> > 35773dac5f86 usb: xhci: Link TRB must not occur within a USB payload burst
>> >
>> > 3. Dan and Mathias can work together to come up with an overall plan to
>> > change the xHCI driver architecture to be fully compliant with the TD
>> > fragment rules. That can be done over the next few kernel releases.
>> >
>> > The end result is that we don't destabilize storage or break userspace
>> > USB drivers, we don't break people's xHCI host controllers,
>> > the ax88179_178a USB ethernet devices still work under xHCI (a bit with
>> > worse performance), and other USB ethernet devices still get the
>> > performance improvement introduced in 3.12.
>>
>> No other usbnet drivers has enabled SG... Which is why you have only
>> seen this problem with the ax88179_178a devices. So there is no
>> performance improvement to keep.
In my test environment, the patch does improve both throughput and
cpu utilization, if you search the previous email for the patch, you can
see the data.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: eth: cpsw: Correctly attach to GPIO bitbang MDIO driver
From: David Miller @ 2014-01-31 0:26 UTC (permalink / raw)
To: sr; +Cc: netdev, lukas.stockmann, mugunthanvnm
In-Reply-To: <1390991557-22522-1-git-send-email-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Wed, 29 Jan 2014 11:32:37 +0100
> When the GPIO bitbang MDIO driver is used instead of the Davinci MDIO driver
> we need to configure the phy_id string differently. Otherwise this string
> looks like this "gpio.6" instead of "gpio-0" and the PHY is not found when
> phy_connect() is called.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Applied.
^ permalink raw reply
* Re: [PATCH net] net/ipv4: Use non-atomic allocation of udp offloads structure instance
From: David Miller @ 2014-01-31 0:26 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, dan.carpenter
In-Reply-To: <1391011739-8597-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 29 Jan 2014 18:08:59 +0200
> Since udp_add_offload() can be called from non-sleepable context e.g
> under this call tree from the vxlan driver use case:
>
> vxlan_socket_create() <-- holds the spinlock
> -> vxlan_notify_add_rx_port()
> -> udp_add_offload() <-- schedules
>
> we should allocate the udp_offloads structure in atomic manner.
>
> Fixes: b582ef0 ('net: Add GRO support for UDP encapsulating protocols')
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net/vxlan: Go over all candidate streams for GRO matching
From: David Miller @ 2014-01-31 0:26 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, therbert, edumazet
In-Reply-To: <1391011810-10682-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 29 Jan 2014 18:10:10 +0200
> The loop in vxlan_gro_receive() over the current set of candidates for
> coalescing was wrongly aborted once a match was found. In rare cases,
> this can cause a false-positives matching in the next layer GRO checks.
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Applied.
^ permalink raw reply
* Re: [Patch net] net: allow setting mac address of loopback device
From: David Miller @ 2014-01-31 0:27 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, stephen, edumazet
In-Reply-To: <1391038731-7501-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 29 Jan 2014 15:38:51 -0800
> We are trying to mirror the local traffic from lo to eth0,
> allowing setting mac address of lo to eth0 would make
> the ether addresses in these packets correct, so that
> we don't have to modify the ether header again.
>
> Since usually no one cares about its mac address (all-zero),
> it is safe to allow those who care to set its mac address.
>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Please resubmit when the net-next tree opens back up.
Thank you.
^ permalink raw reply
* Re: [PATCH stable 3.9+] can: add destructor for self generated skbs
From: David Miller @ 2014-01-31 0:27 UTC (permalink / raw)
To: socketcan; +Cc: eric.dumazet, nautsch2, netdev, linux-can
In-Reply-To: <52EA1740.2010108@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 30 Jan 2014 10:11:28 +0100
> Self generated skbuffs in net/can/bcm.c are setting a skb->sk reference but
> no explicit destructor which is enforced since Linux 3.11 with commit
> 376c7311bdb6 (net: add a temporary sanity check in skb_orphan()).
>
> This patch adds some helper functions to make sure that a destructor is
> properly defined when a sock reference is assigned to a CAN related skb.
> To create an unshared skb owned by the original sock a common helper function
> has been introduced to replace open coded functions to create CAN echo skbs.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> Tested-by: Andre Naujoks <nautsch2@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] e100: Fix "disabling already-disabled device" warning
From: David Miller @ 2014-01-31 0:27 UTC (permalink / raw)
To: michele; +Cc: netdev, e1000-devel, idirectscm
In-Reply-To: <1391079064-18411-1-git-send-email-michele@acksyn.org>
From: Michele Baldessari <michele@acksyn.org>
Date: Thu, 30 Jan 2014 10:51:04 +0000
> In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and
> https://bugzilla.redhat.com/show_bug.cgi?id=970480 we
> received different reports of e100 throwing the following
> warning:
...
> This patch removes pci_disable_device() from __e100_shutdown().
> pci_clear_master() is enough.
>
> Signed-off-by: Michele Baldessari <michele@acksyn.org>
> Tested-by: Mark Harig <idirectscm@aim.com>
Can I get some Intel folks to review/ack this?
Thanks.
^ permalink raw reply
* Re: [PATCH] net: set default DEVTYPE for all ethernet based devices
From: David Miller @ 2014-01-31 0:28 UTC (permalink / raw)
To: teg
Cc: netdev, linux-kernel, stephen, avi.kp.137, mchehab, horms, marcel,
gregkh, kay
In-Reply-To: <1391088002-15650-1-git-send-email-teg@jklm.no>
From: Tom Gundersen <teg@jklm.no>
Date: Thu, 30 Jan 2014 14:20:02 +0100
> In systemd's networkd and udevd, we would like to give the administrator a
> simple way to filter net devices by their DEVTYPE [0][1]. Other software
> such as ConnMan and NetworkManager uses a similar filtering already.
>
> Currently, plain ethernet devices have DEVTYPE=(null). This patch sets the
> devtype to "ethernet" instead. This avoids the need for special-casing the
> DEVTYPE=(null) case in userspace, and also avoids false positives, as there
> are several other types of netdevs that also have DEVTYPE=(null).
>
> Notice that this is done, as suggested by Marcel, in alloc_etherdev_mqs(),
> and as best I can tell it will not give any false positives. I considered
> doing it in ether_setup() instead as that seemed more intuitive, but that
> would give a lot of false positives indeed.
>
> [0]: <http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html#Type>
> [1]: <http://www.freedesktop.org/software/systemd/man/udev.html#Type>
>
> Signed-off-by: Tom Gundersen <teg@jklm.no>
Assuming that all users of alloc_etherdev*() are ethernet devices is
really not going to work.
^ permalink raw reply
* Re: [PATCH] 9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers
From: David Miller @ 2014-01-31 0:29 UTC (permalink / raw)
To: ryao
Cc: ericvh, rminnich, lucho, v9fs-developer, netdev, linux-kernel,
kernel, aneesh.kumar, will.deacon, cov, behlendorf1, mthode
In-Reply-To: <1391104968-10258-2-git-send-email-ryao@gentoo.org>
From: Richard Yao <ryao@gentoo.org>
Date: Thu, 30 Jan 2014 13:02:48 -0500
> The 9p-virtio transport does zero copy on things larger than 1024 bytes
> in size. It accomplishes this by returning the physical addresses of
> pages to the virtio-pci device. At present, the translation is usually a
> bit shift.
>
> However, that approach produces an invalid page address when we
> read/write to vmalloc buffers, such as those used for Linux kernle
> modules. This causes QEMU to die printing:
>
> qemu-system-x86_64: virtio: trying to map MMIO memory
>
> This patch enables 9p-virtio to correctly handle this case. This not
> only enables us to load Linux kernel modules off virtfs, but also
> enables ZFS file-based vdevs on virtfs to be used without killing QEMU.
>
> Also, special thanks to both Avi Kivity and Alexander Graf for their
> interpretation of QEMU backtraces. Without their guidence, tracking down
> this bug would have taken much longer.
>
> Signed-off-by: Richard Yao <ryao@gentoo.org>
> Acked-by: Alexander Graf <agraf@suse.de>
> Reviewed-by: Will Deacon <will.deacon@arm.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] The maintainer needs to be updated.
From: David Miller @ 2014-01-31 0:29 UTC (permalink / raw)
To: venkat.x.venkatsubra; +Cc: netdev, rds-devel, chien.yen
In-Reply-To: <1391117327-10420-1-git-send-email-venkat.x.venkatsubra@oracle.com>
From: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Date: Thu, 30 Jan 2014 13:28:47 -0800
> Signed-off-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Applied.
^ permalink raw reply
* [RFC PATCH] net: core: move core networking work to power efficient workqueue
From: Zoran Markovic @ 2014-01-31 0:33 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Shaibal Dutta, David S. Miller, Jiri Pirko,
YOSHIFUJI Hideaki, Eric Dumazet, Julian Anastasov, Flavio Leitner,
Neil Horman, Patrick McHardy, John Fastabend, Amerigo Wang,
Joe Perches, Jason Wang, Antonio Quartulli, Simon Horman,
Nikolay Aleksandrov, Zoran Markovic
From: Shaibal Dutta <shaibal.dutta@broadcom.com>
This patch moves the following work to the power efficient workqueue:
- Transmit work of netpoll
- Destination cache garbage collector work
- Link watch event handler work
In general, assignment of CPUs to pending work could be deferred to
the scheduler in order to extend idle residency time and improve
power efficiency. I would value community's opinion on the migration
of this work to the power efficient workqueue, with an emphasis on
migration of netpoll's transmit work.
This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: Flavio Leitner <fbl@redhat.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: John Fastabend <john.r.fastabend@intel.com>
Cc: Amerigo Wang <amwang@redhat.com>
Cc: Joe Perches <joe@perches.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Antonio Quartulli <antonio@meshcoding.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Nikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com>
[zoran.markovic@linaro.org: Rebased to latest kernel version. Edited
calls to mod_delayed_work to reference power efficient workqueue.
Added commit message.]
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
---
net/core/dst.c | 5 +++--
net/core/link_watch.c | 5 +++--
net/core/netpoll.c | 6 ++++--
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/net/core/dst.c b/net/core/dst.c
index ca4231e..cc28352 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -135,7 +135,8 @@ loop:
*/
if (expires > 4*HZ)
expires = round_jiffies_relative(expires);
- schedule_delayed_work(&dst_gc_work, expires);
+ queue_delayed_work(system_power_efficient_wq,
+ &dst_gc_work, expires);
}
spin_unlock_bh(&dst_garbage.lock);
@@ -223,7 +224,7 @@ void __dst_free(struct dst_entry *dst)
if (dst_garbage.timer_inc > DST_GC_INC) {
dst_garbage.timer_inc = DST_GC_INC;
dst_garbage.timer_expires = DST_GC_MIN;
- mod_delayed_work(system_wq, &dst_gc_work,
+ mod_delayed_work(system_power_efficient_wq, &dst_gc_work,
dst_garbage.timer_expires);
}
spin_unlock_bh(&dst_garbage.lock);
diff --git a/net/core/link_watch.c b/net/core/link_watch.c
index 9c3a839..0ae3994 100644
--- a/net/core/link_watch.c
+++ b/net/core/link_watch.c
@@ -135,9 +135,10 @@ static void linkwatch_schedule_work(int urgent)
* override the existing timer.
*/
if (test_bit(LW_URGENT, &linkwatch_flags))
- mod_delayed_work(system_wq, &linkwatch_work, 0);
+ mod_delayed_work(system_power_efficient_wq, &linkwatch_work, 0);
else
- schedule_delayed_work(&linkwatch_work, delay);
+ queue_delayed_work(system_power_efficient_wq,
+ &linkwatch_work, delay);
}
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index c03f3de..2c8f839 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -101,7 +101,8 @@ static void queue_process(struct work_struct *work)
__netif_tx_unlock(txq);
local_irq_restore(flags);
- schedule_delayed_work(&npinfo->tx_work, HZ/10);
+ queue_delayed_work(system_power_efficient_wq,
+ &npinfo->tx_work, HZ/10);
return;
}
__netif_tx_unlock(txq);
@@ -423,7 +424,8 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
if (status != NETDEV_TX_OK) {
skb_queue_tail(&npinfo->txq, skb);
- schedule_delayed_work(&npinfo->tx_work,0);
+ queue_delayed_work(system_power_efficient_wq,
+ &npinfo->tx_work, 0);
}
}
EXPORT_SYMBOL(netpoll_send_skb_on_dev);
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH net] e100: Fix "disabling already-disabled device" warning
From: Brown, Aaron F @ 2014-01-31 0:40 UTC (permalink / raw)
To: David Miller, michele@acksyn.org
Cc: netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net,
idirectscm@aim.com
In-Reply-To: <20140130.162745.1556632155972070897.davem@davemloft.net>
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of David Miller
> Sent: Thursday, January 30, 2014 4:28 PM
> To: michele@acksyn.org
> Cc: netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net;
> idirectscm@aim.com
> Subject: Re: [PATCH net] e100: Fix "disabling already-disabled device"
> warning
>
> From: Michele Baldessari <michele@acksyn.org>
> Date: Thu, 30 Jan 2014 10:51:04 +0000
>
> > In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and
> > https://bugzilla.redhat.com/show_bug.cgi?id=970480 we received
> > different reports of e100 throwing the following
> > warning:
> ...
> > This patch removes pci_disable_device() from __e100_shutdown().
> > pci_clear_master() is enough.
> >
> > Signed-off-by: Michele Baldessari <michele@acksyn.org>
> > Tested-by: Mark Harig <idirectscm@aim.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
Sorry if it's a duplicate, one I sent out earlier did not seem to hit netdev.
>
> Can I get some Intel folks to review/ack this?
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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