All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sathya Perla <Sathya.Perla@Emulex.Com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: "jiang.biao2@zte.com.cn" <jiang.biao2@zte.com.cn>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Subramanian Seetharaman <subbu.seetharaman@emulex.com>,
	Ajit Khaparde <Ajit.Khaparde@Emulex.Com>,
	"wang.liang82@zte.com.cn" <wang.liang82@zte.com.cn>,
	"cai.qu@zte.com.cn" <cai.qu@zte.com.cn>,
	"li.fengmao@zte.com.cn" <li.fengmao@zte.com.cn>,
	"long.chun@zte.com.cn" <long.chun@zte.com.cn>,
	David Miller <davem@davemloft.net>
Subject: RE: [PATCH] be2net: Bugfix for packet drop with kernel param swiotlb=force
Date: Mon, 3 Mar 2014 07:24:40 +0000	[thread overview]
Message-ID: <006eeee3-f0de-4b72-8afe-4aff3a6e4c26@CMEXHTCAS2.ad.emulex.com> (raw)
In-Reply-To: <1393635652.14067.104.camel@deadeye.wl.decadent.org.uk>

> -----Original Message-----
> From: Ben Hutchings [mailto:ben@decadent.org.uk]
> 
> On Wed, 2014-02-26 at 04:54 +0000, Sathya Perla wrote:
> > > -----Original Message-----
> > > From: Ben Hutchings [mailto:ben@decadent.org.uk]
> > >
> > ...
> > > > > > >
> > > > > > > From: Li Fengmao <li.fengmao@zte.com.cn>
> > > > > > >
> > > > > > > There will be packet drop with kernel param "swiotlb = force" on
> > > > > > > Emulex 10Gb NIC using be2net driver. The problem is caused by
> > > > > > > receiving skb without calling pci_unmap_page() in get_rx_page_info().
> > > > > > > rx_page_info->last_page_user is initialized to false in
> > > > > > > be_post_rx_frags() when current frag are mapped in the first half of
> > > > > > > the same page with another frag. But in that case with
> > > > > > > "swiotlb = force" param, data can not be copied into the page of
> > > > > > > rx_page_info without calling pci_unmap_page, so the data frag mapped
> > > > > > > in the first half of the page will be dropped.
> > > > > > >
> > > > > > > It can be solved by creating only a mapping relation between frag
> > > > > > > and page, and deleting rx_page_info->last_page_user to ensure
> > > > > > > calling pci_unmap_page when handling each receiving frag.
> > > > > >
> > > > > > This patch uses an entire page for each RX frag (whose default size is 2048).
> > > > > > Consequently, on platforms like ppc64 where the default PAGE_SIZE is 64K,
> > > > > > memory usage becomes very inefficient.
> > > > > >
> > > > > > Instead, I've tried a partial-page mapping scheme. This retains the
> > > > > > page sharing logic, but un-maps each frag separately so that
> > > > > > the data is copied from the bounce buffers.
> > > > > [...]
> > > > >
> > > > > You don't need to map/unmap each fragment separately; you can sync a
> > > > > sub-page range with dma_sync_single_for_cpu().
> > > > >
> > > >
> > > > Ben, after syncing each frag with a dma_sync_single_for_cpu() call,
> > > > would I still need to dma_unmap_page() after DMA is done on all the frags
> > > > of the page? I thought I needed to.
> > >
> > > Yes.
> > >
> > > > I'm confused to see that swiotlb_bounce() (that copies data from the bounce buffers)
> > > > is called from both swiotlb_sync_single_for_cpu() and swiotlb_unmap_page().
> > > > I ofcourse don't want the data to be copied from the bounce buffers twice!
> > >
> > > Right, unmap includes a sync so you should:
> > > - for the last frag per page, dma_unmap_page() only
> > > - for every other frag, dma_sync_single_for_cpu() only
> >
> > Ben, the dma_unmap_page() requires us to pass the same dma_addr and size returned
> by
> > (and passed to) the dma_map_page() call.
> > So, for the last frag, when I call dma_map_page() with the page_addr (and not the
> frag_addr) and the
> > page size, won't it try to copy the data belonging to all the previous frags of page again?!!
> 
> When using bounce buffers (e.g. swiotlb), yes this results in another
> copy, which is inefficient.  But when using a real IOMMU neither
> function will copy.  I would optimise for IOMMUs.

Ok, that sounds right.....thanks for the help!
-Sathya

  reply	other threads:[~2014-03-03  7:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-20  1:56 [PATCH] be2net: Bugfix for packet drop with kernel param swiotlb=force jiang.biao2
2014-02-20  9:39 ` Sathya Perla
     [not found]   ` <OF23C58A81.24C211B9-ON48257C86.0025CED7-48257C86.0026D02E@zte.com.cn>
2014-02-21  7:15     ` Sathya Perla
2014-02-22  1:49   ` Ben Hutchings
2014-02-24  6:43     ` Sathya Perla
2014-02-25 14:06     ` Sathya Perla
2014-02-25 16:58       ` Ben Hutchings
2014-02-26  4:54         ` Sathya Perla
2014-03-01  1:00           ` Ben Hutchings
2014-03-03  7:24             ` Sathya Perla [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-02-19  8:25 jiang.biao2
2014-02-19 21:44 ` David Miller

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=006eeee3-f0de-4b72-8afe-4aff3a6e4c26@CMEXHTCAS2.ad.emulex.com \
    --to=sathya.perla@emulex.com \
    --cc=Ajit.Khaparde@Emulex.Com \
    --cc=ben@decadent.org.uk \
    --cc=cai.qu@zte.com.cn \
    --cc=davem@davemloft.net \
    --cc=jiang.biao2@zte.com.cn \
    --cc=li.fengmao@zte.com.cn \
    --cc=long.chun@zte.com.cn \
    --cc=netdev@vger.kernel.org \
    --cc=subbu.seetharaman@emulex.com \
    --cc=wang.liang82@zte.com.cn \
    /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.