On Wed, 2017-01-25 at 16:13 +0800, Hayes Wang wrote:
> Re-schedule napi after napi_complete() for tx, if it is necessay.
>
> In r8152_poll(), if the tx is completed after tx_bottom() and before
> napi_complete(), the scheduling of napi would be lost. Then, no
> one handles the next tx until the ne
On Wed, 2017-01-25 at 09:39 +, Hayes Wang wrote:
> Oliver Neukum [mailto:oneu...@suse.com]
> > Sent: Wednesday, January 25, 2017 5:35 PM
> [...]
> > looking at r8152 I noticed that it uses NAPI. I never considered
> > this for the generic USB networking code as you cannot disable
> > interrupts
On Mon, 2016-08-29 at 09:32 -0400, robert.f...@collabora.com wrote:
> From: Robert Foss
>
> From: Grant Grundler
>
> The miii_nway_restart() causes a PHY link change activity and
> ax88772_link_reset will be called. link_reset will set
> AX_CMD_WRITE_MEDIUM_MODE register correctly.
>
> The asi
On Thu, 2016-09-01 at 12:47 -0400, Robert Foss wrote:
> I'm not quite sure how the first From line was added, it
> should not have been.
> Grant Grundler is most definitely the author.
>
> Would you like me to resubmit in v++ and make sure that it has been
> corrected?
This is too late, patches
On Sun, 2016-03-20 at 11:43 +0100, Geert Uytterhoeven wrote:
> If CONFIG_PM=n:
>
> drivers/net/usb/lan78xx.c: In function ‘lan78xx_get_stats64’:
> drivers/net/usb/lan78xx.c:3274: error: ‘struct dev_pm_info’ has no member
> named ‘runtime_auto’
>
> If PM is disabled, the runtime_auto flag
On Tue, 2017-01-31 at 11:06 -0800, Guenter Roeck wrote:
> When unloading the r8152 driver using the 'unbind' sysfs attribute
> in a system with KASAN enabled, the following error message is seen
> on a regular basis.
>
> static int alloc_all_mem(struct r8152 *tp)
> @@ -1423,10 +1420,6 @@ static
On Fri, 2017-03-24 at 11:27 +1000, Greg Ungerer wrote:
> Add support for the net stats64 counters to the usbnet core and then to
> the qmi_wwan driver.
>
> This is a strait forward addition of 64bit counters for RX and TX packets
> and byte counts. It is done in the same style as for the other net
On Fri, 2017-03-24 at 15:42 +1000, Greg Ungerer wrote:
> The usbnet core is used by a number of drivers. This patch only
> updates the qmi-wwan driver to use stats64. If you remove the
> dev->stats.rx_* updates all those other driver users will have
> no counts.
I see. Then I guess the u64 stuff
On Thu, 2012-09-06 at 10:50 +0200, Oliver Neukum wrote:
> On Thursday 06 September 2012 10:13:01 Alexey ORISHKO wrote:
> > Rx path:
> > 4. IP packets are cloned to separate skb and length of actual data
> set to eth packet size, while skb size is still the same as skb
> containing full NTB frame.
On Thu, 2012-09-06 at 11:11 +0200, Eric Dumazet wrote:
> Really skb_clone() use should be removed from cdc_ncm_rx_fixup()
>
> Unless you expect 10Gbit speed from this driver, skb_clone() is the
> worst possible strategy.
>
> Allocating fresh skbs of the right size permits bet
On Sat, 2013-07-20 at 17:16 +0800, fre...@asix.com.tw wrote:
> From: Freddy Xin
>
> Disable TSO and SG network features in reset() and bind() functions,
> and check the return value of skb_linearize() in tx_fixup() to prevent
> TX throttling.
>
> Signed-off-by: Freddy Xin
> ---
> drivers/net/u
On Mon, 2013-07-22 at 19:38 +0100, Ben Hutchings wrote:
> On Mon, 2013-07-22 at 11:29 -0700, Grant Grundler wrote:
> > On Mon, Jul 22, 2013 at 10:07 AM, Eric Dumazet
> > wrote:
> > ...
> > > I guess that if a driver does not advertise NETIF_F_SG, this
> >
On Mon, 2013-07-22 at 20:47 +0100, Ben Hutchings wrote:
> On Mon, 2013-07-22 at 11:47 -0700, Eric Dumazet wrote:
> > On Mon, 2013-07-22 at 19:38 +0100, Ben Hutchings wrote:
> > > On Mon, 2013-07-22 at 11:29 -0700, Grant Grundler wrote:
> > > > On Mon, Jul 22,
On Tue, 2013-07-23 at 16:46 -0700, David Miller wrote:
> From: Eric Dumazet
> Date: Mon, 22 Jul 2013 23:10:27 -0700
>
> > On Mon, 2013-07-22 at 20:47 +0100, Ben Hutchings wrote:
> >> The real solution would be for someone to add SG support to the usbnet
> >> c
On Tue, 2013-07-23 at 16:56 -0700, Eric Dumazet wrote:
> > A quick scan shows that smsc75xx, smsc95xx, and ax88179_178a all have
> > this problem.
> >
> > Instead of the patch starting this thread, I'd like to see one that
> > hits all three drivers and remove
From: Eric Dumazet
usbnet doesn't support yet SG, so drivers should not advertise SG or TSO
capabilities, as they allow TCP stack to build large TSO packets that
need to be linearized and might use order-5 pages.
This adds an extra copy overhead and possible allocation failures.
Current
On Thu, 2013-07-25 at 10:28 +0800, Ming Lei wrote:
>
> It depends if size of sg buffer(except for last one) in the sg list can be
> divided by usb endpoint's max packet size(512 or 1024), at least there
> is the constraint:
>
> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h
On Thu, 2013-07-25 at 13:25 +0800, Ming Lei wrote:
> On Thu, Jul 25, 2013 at 1:10 PM, Eric Dumazet wrote:
> > On Thu, 2013-07-25 at 10:28 +0800, Ming Lei wrote:
> >
> >>
> >> It depends if size of sg buffer(except for last one) in the sg list can be
> >>
On Thu, 2013-07-25 at 22:52 +0800, Ming Lei wrote:
> Maybe need to try it with TSO enabled, in my test on ax88179_178a NIC after
> applying your disabling TSO patch, tx throughput is less than 600Mbps, but rx
> is close to 900Mbps.
It looks like TCP stack could for this case allocate linear skbs
On Wed, 2013-07-31 at 16:02 +0200, Oliver Neukum wrote:
> On Wed, 2013-07-31 at 21:50 +0800, Ming Lei wrote:
>
> > In the usbnet case, the driver already supports non-sg well. Actually,
> > all current drivers should support non-sg well because urb->sg wasn't
> > introduced for very long time. We
On Wed, 2013-07-31 at 18:51 +0800, Ming Lei wrote:
> Hi,
>
> This patchset allows drivers to pass sg buffers which size can't be divided
> by max packet size of endpoint if the host controllers support this kind
> of sg buffers.
>
> Previously we add check[1] on the situation and don't allow thes
On Wed, 2013-07-31 at 18:51 +0800, Ming Lei wrote:
> This patch enables 'can_dma_sg' flag for ax88179_178a device
> if the attached host controller supports building packet from
> discontinuous buffers(DMA SG is possible), so both frame header
> and skb data buffers can be passed to usb stack via u
On Thu, 2013-08-01 at 12:41 +0800, Ming Lei wrote:
> From my trace result, lots of linear SKBs are cloned or header-cloned, so
> it needs skb copy too.
>
> Is it normal in xmit path to see cloned SKBs for driver? If not, I can add
> check
> to avoid allocation of 8 bytes header for non-cloned sk
On Thu, 2013-08-01 at 16:10 +0800, Ming Lei wrote:
> On Thu, Aug 1, 2013 at 1:04 PM, Eric Dumazet wrote:
> > On Thu, 2013-08-01 at 12:41 +0800, Ming Lei wrote:
> >
> >> From my trace result, lots of linear SKBs are cloned or header-cloned, so
> >> it needs skb co
From: Eric Dumazet
ax88179_tx_fixup() has quite complex code trying to push 8 bytes
of control data (len/mss), but fails to do it properly for TCP packets,
incurring an extra copy and point of memory allocation failure.
Lets use the simple and approved way.
dev->needed_headroom being 8,
On Thu, 2013-08-01 at 06:49 -0700, Eric Dumazet wrote:
> From: Eric Dumazet
>
> ax88179_tx_fixup() has quite complex code trying to push 8 bytes
> of control data (len/mss), but fails to do it properly for TCP packets,
> incurring an extra copy and point of memory allocation fai
On Thu, 2013-08-01 at 08:30 -0700, Grant Grundler wrote:
> http://lxr.free-electrons.com/source/include/linux/byteorder/generic.h#L111
> http://lxr.free-electrons.com/ident?i=__cpu_to_le32s
>
> IIRC, cpu_to_leXX() macros return the endian "corrected" value.
> In other words, they need to be assig
On Tue, 2013-08-06 at 08:52 +0800, Ming Lei wrote:
> This patch enables 'can_dma_sg' flag for ax88179_178a device
> if the attached host controller supports building packet from
> discontinuous buffers(DMA SG is possible), so TSO can be enabled
> and skb fragment buffers can be passed to usb stack
be passed to usb stack via urb->sg
> directly.
>
> With the patch, system CPU utilization decreased ~50% and throughput
> increased by ~10% when doing iperf client test on one ARM A15 dual
> core board.
>
> Cc: Eric Dumazet
> Cc: Ben Hutchings
> Cc: Grant Grundler
> supporting arbitrary length of sg buffers.
>
> Acked-by: Alan Stern
> Signed-off-by: Ming Lei
> ---
Reviewed-by: Eric Dumazet
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majo
s/usb/host/xhci.c |4
> 1 file changed, 4 insertions(+)
Reviewed-by: Eric Dumazet
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
x_qlen, tx_qlen;
> + unsignedcan_dma_sg:1;
We try to use "unsigned int" instead of plain "unsigned", but its a
minor point and should not block your patches.
Apart from this :
Reviewed-by: Eric Dumazet
--
To unsubscribe from this list: send the line &q
On Fri, 2013-08-09 at 10:40 -0700, Stephen Hemminger wrote:
> On Fri, 9 Aug 2013 14:39:06 -0300
> Fabio Estevam wrote:
>
> > On Fri, Aug 9, 2013 at 2:31 PM, Mark Brown wrote:
> > > From: Mark Brown
> > >
> > > Ensure that the definition of ax88172a_info matches the declaration seen
> > > by use
On Wed, 2013-11-20 at 09:36 +, David Laight wrote:
> Ben said the largest number of fragments from the current network
> stack will be 17, and that none of them will cross 32k boundaries.
> So the network stack won't send down long SG lists.
Please note that skb->head itself _might_ cross a 3
On Mon, 2013-12-09 at 12:47 +0100, Andrzej Pietrasiewicz wrote:
> NOT FOR COMMITTING TO MAINLINE.
>
> With g_ether loaded the sk occasionally becomes 0x.
> It happens usually after transferring few hundreds of kilobytes to few
> tens of megabytes. If sk is 0x then dereferencing it
On Tue, 2013-12-10 at 07:55 +0100, Andrzej Pietrasiewicz wrote:
> W dniu 09.12.2013 16:31, Eric Dumazet pisze:
> > On Mon, 2013-12-09 at 12:47 +0100, Andrzej Pietrasiewicz wrote:
> >> NOT FOR COMMITTING TO MAINLINE.
> >>
> >> With g_ether loaded the sk occa
On Thu, 2014-01-16 at 16:21 +0100, Andrzej Pietrasiewicz wrote:
> W dniu 10.12.2013 15:25, Eric Dumazet pisze:
> > On Tue, 2013-12-10 at 07:55 +0100, Andrzej Pietrasiewicz wrote:
> >> W dniu 09.12.2013 16:31, Eric Dumazet pisze:
> >>> On Mon, 2013-12-09 at 12:47 +010
On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote:
> Drop the tx packet which is more than the size of agg_buf_sz. When
> creating a bridge with the device, we may get the tx packet with
> TSO and the length is more than the gso_max_size which is set by
> the driver through netif_set_gso_max_size
On Wed, 2014-11-26 at 12:06 -0500, David Miller wrote:
> From: Eric Dumazet
> Date: Wed, 26 Nov 2014 08:52:28 -0800
>
> > On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote:
> >> Drop the tx packet which is more than the size of agg_buf_sz. When
> >> creating
On Wed, 2014-12-03 at 13:14 +0800, Hayes Wang wrote:
> If the data size is more than half of the AGG_BUG_SZ, allocate a new
> rx buffer and use skb_clone() to avoid the memory copy.
>
> The original method is that allocate the memory and copy data for each
> packet in a rx buffer. The new one is t
On Wed, 2014-12-03 at 07:05 +, Hayes Wang wrote:
> Eric Dumazet [mailto:eric.duma...@gmail.com]
> > Sent: Wednesday, December 03, 2014 2:08 PM
> [...]
> > Better performance for what workload exactly ?
>
> I test it by using Chariot with 4 Tx and 4 Rx.
> It has abo
On Fri, 2014-12-19 at 06:42 +, Hayes Wang wrote:
> Excuse me. I try to implement ndo_gso_check() with kernel 3.18.
> However, I still get packets with gso and their skb lengths are more
> than the acceptable one. Do I miss something?
>
> +static bool rtl8152_gso_check(struct sk_buff *skb, str
On Fri, 2014-12-19 at 09:36 -0800, Eric Dumazet wrote:
> On Fri, 2014-12-19 at 06:42 +, Hayes Wang wrote:
>
> > Excuse me. I try to implement ndo_gso_check() with kernel 3.18.
> > However, I still get packets with gso and their skb lengths are more
> > than the a
On Tue, 2014-03-04 at 14:35 +, David Laight wrote:
> Does that mean you are splitting the 64k 'ethernet packet' from TCP
> is software? I've looked at the ax88179 where the hardware can do it.
>
> Is there really a gain doing segmentation here if you have to do the
> extra data copy?
There i
On Tue, 2014-03-04 at 20:01 +0800, Hayes Wang wrote:
> +static u32 r8152_xmit_frags(struct r8152 *tp, struct sk_buff *skb, u8 *data)
> +{
> + struct skb_shared_info *info = skb_shinfo(skb);
> + unsigned int cur_frag;
> + u32 total = skb_headlen(skb);
> +
> + memcpy(data, skb->data,
On Tue, 2014-03-04 at 20:01 +0800, Hayes Wang wrote:
> Support scatter gather and TSO.
>
> - netdev->features |= NETIF_F_RXCSUM | NETIF_F_IP_CSUM;
> - netdev->hw_features = NETIF_F_RXCSUM | NETIF_F_IP_CSUM;
> + netdev->features |= NETIF_F_RXCSUM | NETIF_F_IP_CSUM | NETIF_F_SG |
> +
On Tue, 2014-03-04 at 20:01 +0800, Hayes Wang wrote:
> Support hw IPv6 checksum for TCP and UDP packets.
> +/*
> + * r8152_csum_workaround()
> + * The hw limites the value the transport offset. When the offset is out of
> the
> + * range, calculate the checksum by sw.
> + */
> +static void r8152
On Fri, 2014-05-02 at 23:28 +0200, Bjørn Mork wrote:
> Fixes this warning introduced by commit 5b8f15f78e6f
> ("net: cdc_mbim: handle IPv6 Neigbor Solicitations"):
>
> ===
> [ INFO: suspicious RCU usage. ]
> 3.15.0-rc3 #213 Tainted: GW O
> -
On Thu, 2014-05-22 at 20:39 +0100, Jim Baxter wrote:
> I now think that the correct solution here is to create a new smaller
> skb and copy the data from the sub packets into it.
For low speed devices, this is indeed the best way.
(this is called copybreak in some nic drivers)
--
To unsubscri
On Thu, 2014-05-22 at 21:21 +0100, Jim Baxter wrote:
> OK, so it is the value of the memory that has been allocated for the SKB.
> If there are multiple clones for an skb all pointing at the same data,
> will that distort the memory used when they all have the same truesize?
Its always better to
On Thu, 2014-05-22 at 20:07 +0100, Jim Baxter wrote:
>
> I have been investigating a network issue with bursts of network traffic
> over USB CDC-NCM, the issue is that the kernel is dropping packets
> because sk_rcvqueues_full() returns true due to skb2->truesize is always
> 32960 instead of SKB_
On Thu, 2014-05-22 at 13:58 -0700, Eric Dumazet wrote:
> I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not
> use high order allocations.
Correction, that would need SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN),
because drivers/net/usb/usbnet.c calls __netdev_alloc_skb_ip
On Fri, 2014-05-23 at 12:13 +0100, Jim Baxter wrote:
> What are the side effects of changing the truesize, if the original
> uncloned skb has the full truesize then isn't the potential memory usage
> still counted for the avoidance of OOM?
Nope. This can be disastrous.
A malicious remote peer ca
not be freed/reallocated, but recycled,
especially if using 32KB.
But thats a minor detail, this patch is already a huge win for a 21Mbps
device.
Acked-by: Eric Dumazet
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2014-05-23 at 15:30 +, David Laight wrote:
> From: Eric Dumazet
> ...
> > TCP stack uses fast clones, and current stack gives them a truesize of
> > 2048 + sizeof(sk_buff), while it really should be 2048 +
> > 2*sizeof(sk_buff)
> >
> > Luckily, G
On Fri, 2014-05-23 at 08:44 -0700, Rick Jones wrote:
> If you are measuring performance with the likes of netperf, you should
> be able to get an idea of the performance effect from the change in
> service demand (CPU consumed per unit of work) even if the maximum
> throughput remains capped.
2768
So truesize of the skb was infact ~32KB, which is really insane indeed.
After your patch, its back to ~2KB
Acked-by: Eric Dumazet
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 9, 2018 at 8:51 AM, Josef Griebichler
wrote:
> Hi Linus,
>
> your patch works very good for me and others (please see
> https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006).
> No errors in recordings any more.
> The patch was als
On Tue, Jan 9, 2018 at 9:48 AM, Linus Torvalds
wrote:
> On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet wrote:
>>
>> So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has
>> shown up multiple times in various 'regressions'
>> simply
On Tue, Jan 9, 2018 at 10:58 AM, Linus Torvalds
wrote:
> On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet wrote:
>>
>> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate
>> handling', but TCP Small queues heavily use TASKLET,
>> so as far as I
On Fri, 2018-01-12 at 19:13 -0200, Mauro Carvalho Chehab wrote:
>
>
> The .config file used to build the Kernel is at:
> https://pastebin.com/wpZghann
>
Hi Mauro
Any chance you can try CONFIG_HZ_1000=y, CONFIG_HZ=1000 ?
Thanks.
--
To unsubscribe from this list: send the line "unsubscri
On Tue, 2018-02-27 at 08:26 +0100, Marek Szyprowski wrote:
> Hi
>
> I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel
> warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No
> special activity is needed to reproduce this issue, it happens almost
> on every
On Tue, 2018-02-27 at 15:42 +0100, Marek Szyprowski wrote:
> Hi Eric,
>
> On 2018-02-27 15:07, Eric Dumazet wrote:
> > On Tue, 2018-02-27 at 08:26 +0100, Marek Szyprowski wrote:
> > > I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel
> >
On Tue, 2018-02-27 at 07:09 -0800, Eric Dumazet wrote:
>
> Note that for this one, it seems we also could perform stats updates in
> BH context, since skb is queued via defer_bh()
>
> But simplicity wins I guess.
Thinking more about this, I am not sure we have any guarantee tha
On Mon, 2018-03-05 at 12:46 +0100, Oliver Neukum wrote:
> On Mon, 2018-03-05 at 08:45 +0100, Marek Szyprowski wrote:
> > Hi Oliver,
> >
> > On 2018-02-27 17:07, Oliver Neukum wrote:
> > > Am Dienstag, den 27.02.2018, 07:13 -0800 schrieb Eric Dumazet:
> > &
From: Eric Dumazet
Marek reported a LOCKDEP issue occurring on 32bit host,
that we tracked down to the fact that usbnet could either
run from soft or hard irqs.
This patch adds u64_stats_update_begin_irqsave() and
u64_stats_update_end_irqrestore() helpers to solve this case.
[ 17.768040
On 8/13/19 5:42 AM, Hayes Wang wrote:
> Use skb_add_rx_frag() to reduce the memory copy for rx data.
>
> Use a new list of rx_used to store the rx buffer which couldn't be
> reused yet.
>
> Besides, the total number of rx buffer may be increased or decreased
> dynamically. And it is limited by
67 matches
Mail list logo
