[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20130123.134726.112187775032509711.davem@davemloft.net>
Date: Wed, 23 Jan 2013 13:47:26 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: bjorn@...k.no
Cc: netdev@...r.kernel.org, linux-usb@...r.kernel.org, oneukum@...e.de,
gsuarez@...thmicro.com, alexey.orishko@...ricsson.com,
y.kaliuta@...il.com
Subject: Re: [PATCH net] net: cdc_mbim: send ZLP only for the specific
buggy device
From: Bjørn Mork <bjorn@...k.no>
Date: Wed, 23 Jan 2013 11:57:02 +0100
> Reverting 328d7b8 and instead adding an exception for the
> Sierra Wireless MC7710.
>
> commit 328d7b8 (net: cdc_mbim: send ZLP after max sized NTBs)
> added a workaround for an issue observed on one specific device.
> Concerns were raised that this workaround adds a performance
> penalty to all devices based on questionable, if not buggy,
> behaviour of a single device:
>
> "If you add ZLP for NTBs of dwNtbOutMaxSize, you are heavily affecting CPU
> load, increasing interrupt load by factor of 2 in high load traffic
> scenario and possibly decreasing throughput for all other devices
> which behaves correctly."
>
> "The idea of NCM was to avoid extra ZLPs. If your transfer is exactly
> dwNtbOutMaxSize, it's known, you can submit such request on the receiver
> side and you do not need any EOT indicatation, so the frametime can be
> used for useful data."
>
> Adding a device specific exception to prevent the workaround from
> affecting well behaved devices.
>
> The assumption here is that needing a ZLP is truly an *exception*.
> We do not yet have enough data to verify this. The generic
> workaround in commit 328d7b8 should be considered acceptable despite
> the performance penalty if the exception list becomes a maintainance
> hassle.
>
> Cc: Alexey ORISHKO <alexey.orishko@...ricsson.com>
> Cc: Yauheni Kaliuta <y.kaliuta@...il.com>
> Signed-off-by: Bjørn Mork <bjorn@...k.no>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists