From: Suwan Kim <suwan.kim027@gmail.com>
To: shuah <shuah@kernel.org>
Cc: stern@rowland.harvard.edu, valentina.manea.m@gmail.com,
gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] usbip: Skip DMA mapping and unmapping for urb at vhci
Date: Mon, 1 Jul 2019 18:29:34 +0900 [thread overview]
Message-ID: <20190701092932.GA3939@localhost.localdomain> (raw)
In-Reply-To: <10a4f10a-d271-9331-b847-bdc06f9fc9cf@kernel.org>
On Fri, Jun 28, 2019 at 06:11:54PM -0600, shuah wrote:
> Hi Suwan,
>
> On 6/21/19 11:45 AM, Suwan Kim wrote:
> > vhci doesn’t do dma for remote device. Actually, the real dma
> > operation is done by network card driver. So, vhci doesn’t use and
> > need dma address of transfer buffer of urb.
> >
> > When vhci supports SG, it is useful to use native SG list instead
> > of mapped SG list because dma mapping fnuction can adjust the
> > number of SG list that is urb->num_mapped_sgs.
> >
> > But hcd provides dma mapping and unmapping function by defualt.
>
> Typo "defualt"
>
> > Moreover, it causes unnecessary dma mapping and unmapping which
> > will be done again at the NIC driver and it wastes CPU cycles.
> > So, implement map_urb_for_dma and unmap_urb_for_dma function for
> > vhci in order to skip the dma mapping and unmapping procedure.
> >
>
> How did you verify that unnecessary dma map/unmap are happening?
> How many CPU cycles did you manage to reduce with this change?
Dma mapping/unmapping is not required for vhci because vhci passes
the virtual address of the buffer to the network stack without
passing the dma address of the buffer. Network stack receive the
virtual address of the buffer from vhci and later, network card
driver performs dma mapping for the buffer. So, as far as I know,
dma address of the buffer is not used for vhci and virtual address
is only used by vhci.
I used ftrace to measure a duration of usb_hcd_map_urb_for_dma().
As a result, usb_hcd_map_urb_for_dma() took a duration of about
0.14us out of about 10us which is the duration of usb_hcd_submit_urb().
However, this figure is the dma mapping measurement value for
physically contiguous buffers when vhci does not support SG, and
if vhci supports SG, more CPU cycles will be consumed for SG dma
mapping.
I think that the important point is dma mapping/unmapping is
unnecessary at vhci. So we can skip dma mapping/unmapping and save
the CPU cycles (even if it is small). This is an opportunity to
reduce the end-to-end latency of usbip and improve the performance.
Regards
Suwan Kim
next prev parent reply other threads:[~2019-07-01 9:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-21 17:45 [PATCH 0/2] usbip: Implement SG support to vhci Suwan Kim
2019-06-21 17:45 ` [PATCH 1/2] usbip: Skip DMA mapping and unmapping for urb at vhci Suwan Kim
2019-06-29 0:11 ` shuah
2019-07-01 9:29 ` Suwan Kim [this message]
2019-06-21 17:45 ` [PATCH 2/2] usbip: Implement SG support to vhci Suwan Kim
2019-06-21 20:05 ` Alan Stern
2019-06-24 14:58 ` Suwan Kim
2019-06-24 17:24 ` Alan Stern
2019-07-04 17:24 ` Suwan Kim
2019-07-05 1:41 ` Alan Stern
2019-07-05 9:07 ` Suwan Kim
2019-06-22 10:40 ` kbuild test robot
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=20190701092932.GA3939@localhost.localdomain \
--to=suwan.kim027@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=valentina.manea.m@gmail.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).