linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: "Jakub Kiciński" <moorray3@wp.pl>
Cc: Kalle Valo <kvalo@codeaurora.org>,
	Felix Fietkau <nbd@openwrt.org>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Jakub Kicinski <kubakici@wp.pl>
Subject: Re: [PATCH 1/2] add mt7601u driver
Date: Tue, 05 May 2015 08:45:42 +0200	[thread overview]
Message-ID: <1430808342.1950.6.camel@sipsolutions.net> (raw)
In-Reply-To: <20150505024949.0a672dd1@north>

On Tue, 2015-05-05 at 02:49 +0200, Jakub Kiciński wrote:
> On Mon, 04 May 2015 12:15:11 +0200, Johannes Berg wrote:
> > On Mon, 2015-05-04 at 12:04 +0200, Jakub Kiciński wrote:
> > 
> > > > Don't know how your buffers are set up, but if the DMA engine consumes
> > > > pages you could consider using paged RX instead of the memcpy().
> > > 
> > > DMA engine can concatenate multiple frames into a single USB bulk
> > > transfer to a large continuous buffer.  There is no way to request 
> > > any alignment of the frames within that large buffer so I think paged 
> > > RX is not an option.
> > 
> > You could probably still do it because the networking stack only
> > requires the *headers* to be aligned. But if they headers aren't in the
> > skb->data (skb->head) then they'll be pulled into that by the network
> > stack, where they'll be aligned.
> 
> I *think* I got it.  Would you care to take a look?  I basically
> allocate a compound page with dev_alloc_pages() and run get_page() for
> every fragment.

I think it looks fine - except the compound part. I'm pretty sure you
need to do references always with the pointer to the first page (and
consequently don't need to split on the page boundary, and use the same
page pointer just with a bigger offset)

> +static void mt7601u_rx_add_frags(struct mt7601u_dev *dev, struct sk_buff *skb,
> +				 void *data, u32 true_len, u32 truesize,
> +				 struct page *p)
> +{
> +	unsigned long addr = (unsigned long) data;
> +	u32 overpage = 0;
> +	u32 p_off = (data - page_address(p)) >> PAGE_SHIFT;

i.e. you shouldn't need p_off

> +	if ((addr & ~PAGE_MASK) + true_len > PAGE_SIZE)
> +		overpage = (addr & ~PAGE_MASK) + true_len - PAGE_SIZE;

nor overpage

> +	skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, p + p_off,
> +			addr & ~PAGE_MASK, true_len - overpage, truesize);
> +	get_page(p + p_off);

Here just use

	skb_fill_page_desc(skb, i, p, data - page_address(p),
			 true_len, truesize);
	get_page(p);

I believe.

> +	/* Do we really need to split the buffer if it crosses a page boundary?
> +	 * Does networking code care?
> +	 */
> +	if (overpage) {
> +		skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, p + p_off + 1,
> +				0, overpage, 0);
> +		get_page(p + p_off + 1);
> +	}
> +}

and this goes away

> +static void mt7601u_rx_process_seg_paged(struct mt7601u_dev *dev, u8 *data,
> +					 u32 seg_len, struct page *p)

[...]

> +	skb = __netdev_alloc_skb(NULL, 256, GFP_ATOMIC);
> +	if (!skb)
> +		return;

We have a comment on this code (from Eric) saying

        /* Dont use dev_alloc_skb(), we'll have enough headroom once   
         * ieee80211_hdr pulled.

which probably applies here as well. We also just use 128 instead of 256
and haven't seen a need for more.

We also pull the entire frame only if it fits into those 128 bytes, and
we preload the 802.11 header + 8 bytes for snap and possibly crypto
headroom so we can do it all at once instead of later in multiple
places. You can check out iwl_mvm_pass_packet_to_mac80211() to see the
details.

johannes


  reply	other threads:[~2015-05-05  6:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-02 13:01 [PATCH 0/2] add mt7601u driver moorray3
2015-05-02 13:01 ` [PATCH 1/2] " moorray3
2015-05-04  9:37   ` Johannes Berg
2015-05-04 10:04     ` Jakub Kiciński
2015-05-04 10:15       ` Johannes Berg
2015-05-05  0:49         ` Jakub Kiciński
2015-05-05  6:45           ` Johannes Berg [this message]
2015-05-05 10:44             ` Jakub Kiciński
2015-05-02 13:01 ` [PATCH 2/2] add mt7601u build infrastructure and co moorray3
2015-05-05 20:22 ` [PATCHv2 0/2] add mt7601u driver Jakub Kicinski
2015-05-05 20:22   ` [PATCHv2 1/2] " Jakub Kicinski
2015-05-05 20:22   ` [PATCHv2 2/2] add mt7601u kbuild and others Jakub Kicinski
2015-05-25  8:13   ` [PATCHv2 0/2] add mt7601u driver Kalle Valo
2015-05-25  9:35     ` Jakub Kiciński
2015-05-26  7:16       ` Johannes Berg
2015-05-25  9:34 ` [PATCHv3 " Jakub Kicinski
2015-05-25  9:34   ` [PATCHv3 1/2] " Jakub Kicinski
2015-05-25  9:34   ` [PATCHv3 2/2] add mt7601u kbuild and others Jakub Kicinski
2015-05-26 10:26   ` [PATCHv3 0/2] add mt7601u driver Kalle Valo
2015-05-26  9:16 ` [PATCHv4] " Jakub Kicinski
2015-05-28  8:36   ` Kalle Valo

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=1430808342.1950.6.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=kubakici@wp.pl \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=moorray3@wp.pl \
    --cc=nbd@openwrt.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).