All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: "Macpaul Lin" <macpaul.lin@mediatek.com>,
	"Chunfeng Yun" <chunfeng.yun@mediatek.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Sergey Organov" <sorganov@gmail.com>,
	"Fabrice Gasnier" <fabrice.gasnier@st.com>,
	linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Mediatek WSD Upstream <wsd_upstream@mediatek.com>,
	Macpaul Lin <macpaul.lin@mediatek.com>,
	Macpaul Lin <macpaul.lin@gmail.com>
Subject: Re: [PATCH 2/2] usb: gadget: u_serial: improve performance for large data
Date: Wed, 24 Jun 2020 09:48:45 +0300	[thread overview]
Message-ID: <87tuz1vu0i.fsf@kernel.org> (raw)
In-Reply-To: <1592310884-4307-2-git-send-email-macpaul.lin@mediatek.com>

[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]


Hi,

Macpaul Lin <macpaul.lin@mediatek.com> writes:

> If the hardware (like DMA engine) could support large usb request exceeds
> maximum packet size, use larger buffer when performing Rx/Tx could reduce
> request numbers and improve performance.
>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
>  drivers/usb/gadget/function/u_serial.c |    9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
> index 3cfc6e2..cdcc070 100644
> --- a/drivers/usb/gadget/function/u_serial.c
> +++ b/drivers/usb/gadget/function/u_serial.c
> @@ -80,6 +80,8 @@
>  #define QUEUE_SIZE		16
>  #define WRITE_BUF_SIZE		8192		/* TX only */
>  #define GS_CONSOLE_BUF_SIZE	8192
> +/* for hardware can do more than max packet */
> +#define REQ_BUF_SIZE		4096
>  
>  /* console info */
>  struct gs_console {
> @@ -247,7 +249,8 @@ static int gs_start_tx(struct gs_port *port)
>  			break;
>  
>  		req = list_entry(pool->next, struct usb_request, list);
> -		len = gs_send_packet(port, req->buf, in->maxpacket);
> +		len = gs_send_packet(port, req->buf, in->can_exceed_maxp ?
> +				REQ_BUF_SIZE : in->maxpacket);

just do this unconditionally.

>  		if (len == 0) {
>  			wake_up_interruptible(&port->drain_wait);
>  			break;
> @@ -514,7 +517,9 @@ static int gs_alloc_requests(struct usb_ep *ep, struct list_head *head,
>  	 * be as speedy as we might otherwise be.
>  	 */
>  	for (i = 0; i < n; i++) {
> -		req = gs_alloc_req(ep, ep->maxpacket, GFP_ATOMIC);
> +		req = gs_alloc_req(ep, ep->can_exceed_maxp ?
> +					REQ_BUF_SIZE : ep->maxpacket,
> +					GFP_ATOMIC);

allocating 4kiB in atomic isn't very good. A better idea would be to
preallocate a list of requests and recycle them, rather than allocating
every time you need to do a transfer

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: "Macpaul Lin" <macpaul.lin@mediatek.com>,
	"Chunfeng Yun" <chunfeng.yun@mediatek.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Sergey Organov" <sorganov@gmail.com>,
	"Fabrice Gasnier" <fabrice.gasnier@st.com>,
	linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Macpaul Lin <macpaul.lin@gmail.com>,
	Macpaul Lin <macpaul.lin@mediatek.com>,
	Mediatek WSD Upstream <wsd_upstream@mediatek.com>
Subject: Re: [PATCH 2/2] usb: gadget: u_serial: improve performance for large data
Date: Wed, 24 Jun 2020 09:48:45 +0300	[thread overview]
Message-ID: <87tuz1vu0i.fsf@kernel.org> (raw)
In-Reply-To: <1592310884-4307-2-git-send-email-macpaul.lin@mediatek.com>


[-- Attachment #1.1: Type: text/plain, Size: 1911 bytes --]


Hi,

Macpaul Lin <macpaul.lin@mediatek.com> writes:

> If the hardware (like DMA engine) could support large usb request exceeds
> maximum packet size, use larger buffer when performing Rx/Tx could reduce
> request numbers and improve performance.
>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
>  drivers/usb/gadget/function/u_serial.c |    9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
> index 3cfc6e2..cdcc070 100644
> --- a/drivers/usb/gadget/function/u_serial.c
> +++ b/drivers/usb/gadget/function/u_serial.c
> @@ -80,6 +80,8 @@
>  #define QUEUE_SIZE		16
>  #define WRITE_BUF_SIZE		8192		/* TX only */
>  #define GS_CONSOLE_BUF_SIZE	8192
> +/* for hardware can do more than max packet */
> +#define REQ_BUF_SIZE		4096
>  
>  /* console info */
>  struct gs_console {
> @@ -247,7 +249,8 @@ static int gs_start_tx(struct gs_port *port)
>  			break;
>  
>  		req = list_entry(pool->next, struct usb_request, list);
> -		len = gs_send_packet(port, req->buf, in->maxpacket);
> +		len = gs_send_packet(port, req->buf, in->can_exceed_maxp ?
> +				REQ_BUF_SIZE : in->maxpacket);

just do this unconditionally.

>  		if (len == 0) {
>  			wake_up_interruptible(&port->drain_wait);
>  			break;
> @@ -514,7 +517,9 @@ static int gs_alloc_requests(struct usb_ep *ep, struct list_head *head,
>  	 * be as speedy as we might otherwise be.
>  	 */
>  	for (i = 0; i < n; i++) {
> -		req = gs_alloc_req(ep, ep->maxpacket, GFP_ATOMIC);
> +		req = gs_alloc_req(ep, ep->can_exceed_maxp ?
> +					REQ_BUF_SIZE : ep->maxpacket,
> +					GFP_ATOMIC);

allocating 4kiB in atomic isn't very good. A better idea would be to
preallocate a list of requests and recycle them, rather than allocating
every time you need to do a transfer

-- 
balbi

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: "Macpaul Lin" <macpaul.lin@mediatek.com>,
	"Chunfeng Yun" <chunfeng.yun@mediatek.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Sergey Organov" <sorganov@gmail.com>,
	"Fabrice Gasnier" <fabrice.gasnier@st.com>,
	linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Macpaul Lin <macpaul.lin@gmail.com>,
	Macpaul Lin <macpaul.lin@mediatek.com>,
	Mediatek WSD Upstream <wsd_upstream@mediatek.com>
Subject: Re: [PATCH 2/2] usb: gadget: u_serial: improve performance for large data
Date: Wed, 24 Jun 2020 09:48:45 +0300	[thread overview]
Message-ID: <87tuz1vu0i.fsf@kernel.org> (raw)
In-Reply-To: <1592310884-4307-2-git-send-email-macpaul.lin@mediatek.com>


[-- Attachment #1.1: Type: text/plain, Size: 1911 bytes --]


Hi,

Macpaul Lin <macpaul.lin@mediatek.com> writes:

> If the hardware (like DMA engine) could support large usb request exceeds
> maximum packet size, use larger buffer when performing Rx/Tx could reduce
> request numbers and improve performance.
>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
>  drivers/usb/gadget/function/u_serial.c |    9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
> index 3cfc6e2..cdcc070 100644
> --- a/drivers/usb/gadget/function/u_serial.c
> +++ b/drivers/usb/gadget/function/u_serial.c
> @@ -80,6 +80,8 @@
>  #define QUEUE_SIZE		16
>  #define WRITE_BUF_SIZE		8192		/* TX only */
>  #define GS_CONSOLE_BUF_SIZE	8192
> +/* for hardware can do more than max packet */
> +#define REQ_BUF_SIZE		4096
>  
>  /* console info */
>  struct gs_console {
> @@ -247,7 +249,8 @@ static int gs_start_tx(struct gs_port *port)
>  			break;
>  
>  		req = list_entry(pool->next, struct usb_request, list);
> -		len = gs_send_packet(port, req->buf, in->maxpacket);
> +		len = gs_send_packet(port, req->buf, in->can_exceed_maxp ?
> +				REQ_BUF_SIZE : in->maxpacket);

just do this unconditionally.

>  		if (len == 0) {
>  			wake_up_interruptible(&port->drain_wait);
>  			break;
> @@ -514,7 +517,9 @@ static int gs_alloc_requests(struct usb_ep *ep, struct list_head *head,
>  	 * be as speedy as we might otherwise be.
>  	 */
>  	for (i = 0; i < n; i++) {
> -		req = gs_alloc_req(ep, ep->maxpacket, GFP_ATOMIC);
> +		req = gs_alloc_req(ep, ep->can_exceed_maxp ?
> +					REQ_BUF_SIZE : ep->maxpacket,
> +					GFP_ATOMIC);

allocating 4kiB in atomic isn't very good. A better idea would be to
preallocate a list of requests and recycle them, rather than allocating
every time you need to do a transfer

-- 
balbi

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-06-24  6:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-16 12:34 [PATCH 1/2] usb: gadget: introduce flag for large request Macpaul Lin
2020-06-16 12:34 ` Macpaul Lin
2020-06-16 12:34 ` Macpaul Lin
2020-06-16 12:34 ` [PATCH 2/2] usb: gadget: u_serial: improve performance for large data Macpaul Lin
2020-06-16 12:34   ` Macpaul Lin
2020-06-16 12:34   ` Macpaul Lin
2020-06-24  6:48   ` Felipe Balbi [this message]
2020-06-24  6:48     ` Felipe Balbi
2020-06-24  6:48     ` Felipe Balbi
2020-06-16 14:02 ` [PATCH 1/2] usb: gadget: introduce flag for large request Alan Stern
2020-06-16 14:02   ` Alan Stern
2020-06-16 14:02   ` Alan Stern
2020-06-17  2:27   ` Macpaul Lin
2020-06-17  2:27     ` Macpaul Lin
2020-06-17  2:27     ` Macpaul Lin
2020-06-17  2:46 ` [PATCH v2] usb: gadget: u_serial: improve performance for large data Macpaul Lin
2020-06-17  2:46   ` Macpaul Lin
2020-06-17  2:46   ` Macpaul Lin
2020-06-17  5:14   ` Greg Kroah-Hartman
2020-06-17  5:14     ` Greg Kroah-Hartman
2020-06-17  5:14     ` Greg Kroah-Hartman
2020-06-17  5:34     ` Macpaul Lin
2020-06-17  5:34       ` Macpaul Lin
2020-06-17  5:34       ` Macpaul Lin
2020-06-17  5:42   ` [PATCH v3] " Macpaul Lin
2020-06-17  5:42     ` Macpaul Lin
2020-06-17  5:42     ` Macpaul Lin
2020-06-24  6:50     ` Felipe Balbi
2020-06-24  6:50       ` Felipe Balbi
2020-06-24  6:50       ` Felipe Balbi
2020-06-24  6:47 ` [PATCH 1/2] usb: gadget: introduce flag for large request Felipe Balbi
2020-06-24  6:47   ` Felipe Balbi
2020-06-24  6:47   ` Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tuz1vu0i.fsf@kernel.org \
    --to=balbi@kernel.org \
    --cc=chunfeng.yun@mediatek.com \
    --cc=fabrice.gasnier@st.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=macpaul.lin@gmail.com \
    --cc=macpaul.lin@mediatek.com \
    --cc=matthias.bgg@gmail.com \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=sorganov@gmail.com \
    --cc=wsd_upstream@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.