All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>,
	kvalo@codeaurora.org, linux-wireless@vger.kernel.org,
	nbd@nbd.name
Subject: Re: [PATCH v3 wireless-drivers 3/3] mt76: usb: do not always copy the first part of received frames
Date: Fri, 14 Jun 2019 12:22:48 +0200	[thread overview]
Message-ID: <20190614102247.GB2669@localhost.localdomain> (raw)
In-Reply-To: <20190614075303.GB3395@redhat.com>

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

> On Thu, Jun 13, 2019 at 11:43:13PM +0200, Lorenzo Bianconi wrote:
> > Set usb buffer size taking into account skb_shared_info in order to
> > not always copy the first part of received frames if A-MSDU is enabled
> > for SG capable devices. Moreover align usb buffer size to max_ep
> > boundaries and set buf_size to PAGE_SIZE even for sg case
> 
> I think this should not be applied to wirless-drivers, only first patch
> that fix the bug and optimizations should be done in -next.

ack, right. I think patch 2/3 and 3/3 can go directly in Felix's tree

> 
> > +	int i, data_size;
> >  
> > +	data_size = rounddown(SKB_WITH_OVERHEAD(q->buf_size),
> > +			      dev->usb.in_ep[MT_EP_IN_PKT_RX].max_packet);
> >  	for (i = 0; i < nsgs; i++) {
> >  		struct page *page;
> >  		void *data;
> > @@ -302,7 +304,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct mt76_queue *q, struct urb *urb,
> >  
> >  		page = virt_to_head_page(data);
> >  		offset = data - page_address(page);
> > -		sg_set_page(&urb->sg[i], page, q->buf_size, offset);
> > +		sg_set_page(&urb->sg[i], page, data_size, offset);
> <snip>
> > -	q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
> >  	q->ndesc = MT_NUM_RX_ENTRIES;
> > +	q->buf_size = PAGE_SIZE;
> > +
> 
> This should be associated with decrease of MT_SG_MAX_SIZE to value that
> is actually needed and currently this is 2 for 4k AMSDU.

MT_SG_MAX_SIZE is used even on tx side and I do not think we will end up with a
huge difference here

> 
> However I don't think allocating 2 pages to avoid ieee80211 header and SNAP
> copy is worth to do. For me best approach would be allocate 1 page for
> 4k AMSDU, 2 for 8k and 3 for 12k (still using sg, but without data_size
> change to avoid 32B copying).

From my point of view it is better to avoid copying if it is possible. Are you
sure there is no difference?

Regards,
Lorenzo

> 
> Stanislaw

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

  reply	other threads:[~2019-06-14 10:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-13 21:43 [PATCH v3 wireless-drivers 0/3] mt76: usb: fix A-MSDU support Lorenzo Bianconi
2019-06-13 21:43 ` [PATCH v3 wireless-drivers 1/3] mt76: usb: fix rx " Lorenzo Bianconi
2019-06-14  7:24   ` Stanislaw Gruszka
2019-06-14 10:11     ` Lorenzo Bianconi
2019-06-14 10:20       ` Johannes Berg
2019-06-14 11:31         ` Stanislaw Gruszka
2019-06-14 11:34           ` Johannes Berg
2019-06-15 12:06           ` Lorenzo Bianconi
2019-06-14 11:14       ` Stanislaw Gruszka
2019-06-14 12:32         ` Lorenzo Bianconi
2019-06-13 21:43 ` [PATCH v3 wireless-drivers 2/3] mt76: mt76u: introduce mt76u_ep data structure Lorenzo Bianconi
2019-06-13 21:43 ` [PATCH v3 wireless-drivers 3/3] mt76: usb: do not always copy the first part of received frames Lorenzo Bianconi
2019-06-14  7:53   ` Stanislaw Gruszka
2019-06-14 10:22     ` Lorenzo Bianconi [this message]
2019-06-14 11:04       ` Stanislaw Gruszka
2019-06-14 12:46         ` Lorenzo Bianconi
2019-06-15  9:40           ` Stanislaw Gruszka
2019-06-19 20:09             ` Lorenzo Bianconi

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=20190614102247.GB2669@localhost.localdomain \
    --to=lorenzo.bianconi@redhat.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=nbd@nbd.name \
    --cc=sgruszka@redhat.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.