netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Ajit Khaparde <ajitk@serverengines.com>
Cc: "mcarlson@broadcom.com" <mcarlson@broadcom.com>,
	"mchan@broadcom.com" <mchan@broadcom.com>,
	"sathyap@serverengines.com" <sathyap@serverengines.com>,
	"subbus@serverengines.com" <subbus@serverengines.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [RFC PATCH 00/10] Remove skb_dma_map/unmap calls
Date: Wed, 25 Nov 2009 09:25:33 -0800	[thread overview]
Message-ID: <4B0D688D.4020904@intel.com> (raw)
In-Reply-To: <20091125113050.GA19837@serverengines.com>

Ajit Khaparde wrote:
> On 24/11/09 17:20 -0800, Alexander Duyck wrote:
>> This patch series removes the skb_dma_map and skb_dma_unmap function calls.
>> The reason for this change is because the use of skb_dma_map/unmap can lead
>> to serious issues when HW IOMMU is enabled.  This is because each mapping
>> of the skb with a HW IOMMU enabled results in a new set of DMA mappings.
>> This in turn leads to issues when skbs are cloned for uses such as
>> bridging or pktgen because each transmitting device will update the skb
>> shared info structure resulting in some mappings being overwritten, and others
>> being freed multiple times.
> 
> If this is the case can the members related to the dma mapping stuff
> (skb_shinfo(skb)->dma_maps) be moved out of this shared info structure and
> we retain this "good" abstraction provided by this skb_dma_map/unmap api?

I had submitted a patch on November 5th that tried to move the maps out 
of the shared info structure and into the sk_buff itself.  That was 
rejected and it was suggested to go back to what was there before since 
not enough drivers were using the skb_dma_map/unmap calls to justify 
increasing the size of an sk_buff.

The biggest issue is that you end up needing to retain a copy of the DMA 
mapping output each time it is called and so the easiest place to retain 
the information is within the transmit buffer driver specific data 
structure.

>> I am looking for input specifically on the tg3, be2net, and bnx2 driver
>> patches as I am not very familiar with them and I am not certain if
>> additional changes are required.
> 
>>       be2net: remove use of skb_dma_map/unmap
>>
>>  drivers/net/benet/be_main.c    |   37 ++++++---
> 
> We have pulled the be2net specific patch for testing and review.
> We will send an update once done with it.
> 
> -Ajit

Thanks for taking a look at this.

Alex

  reply	other threads:[~2009-11-25 17:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-25  1:20 [RFC PATCH 00/10] Remove skb_dma_map/unmap calls Alexander Duyck
2009-11-25  1:20 ` [RFC PATCH 01/10] e1000e: remove use of skb_dma_map from e1000e driver Alexander Duyck
2009-11-25  1:20 ` [RFC PATCH 02/10] e1000: remove use of skb_dma_map from e1000 driver Alexander Duyck
2009-11-25  1:20 ` [RFC PATCH 03/10] ixgb: remove use of skb_dma_map from ixgb Alexander Duyck
2009-11-25  1:20 ` [RFC PATCH 04/10] ixgbe: remove skb_dma_map/unmap calls from driver Alexander Duyck
2009-11-25  1:20 ` [RFC PATCH 05/10] igb: remove use of skb_dma_map " Alexander Duyck
2009-11-25  1:20 ` [RFC PATCH 06/10] igbvf: remove skb_dma_map/unmap call from drivers Alexander Duyck
2009-11-25  1:20 ` [RFC PATCH 07/10] bnx2: remove skb_dma_map/unmap calls from driver Alexander Duyck
2009-11-30 10:26   ` Michael Chan
2009-12-01  0:17     ` Michael Chan
2009-11-25  1:20 ` [RFC PATCH 08/10] be2net: remove use of skb_dma_map/unmap Alexander Duyck
2009-11-27  8:58   ` Ajit Khaparde
2009-11-25  1:20 ` [RFC PATCH 09/10] tg3: " Alexander Duyck
2009-11-25  1:21 ` [RFC PATCH 10/10] skbuff: remove skb_dma_map/unmap Alexander Duyck
2009-11-25 11:30 ` [RFC PATCH 00/10] Remove skb_dma_map/unmap calls Ajit Khaparde
2009-11-25 17:25   ` Alexander Duyck [this message]
2009-11-30  7:40 ` David Miller
2009-12-01  1:03   ` Duyck, Alexander H
2009-12-01  4:16     ` David Miller
2009-12-01  4:34       ` Eric Dumazet

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=4B0D688D.4020904@intel.com \
    --to=alexander.h.duyck@intel.com \
    --cc=ajitk@serverengines.com \
    --cc=davem@davemloft.net \
    --cc=mcarlson@broadcom.com \
    --cc=mchan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=sathyap@serverengines.com \
    --cc=subbus@serverengines.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 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).