linux-kernel - zero copy in usbip send and recieve path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 Apr 2010 16:27:46 +0530
From:	"B.Vinai Kumar" <vinaibangala2001@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-usb <linux-usb@...r.kernel.org>,
	usbip-devel@...ts.sourceforge.net,
	Takahiro Hirofuchi <hirofuchi@...rs.sourceforge.net>
Subject: zero copy in usbip send and recieve path

Hi All,

I'am trying to implement zero copy in USBIP while sending / receiving
usbip packets.

I started it with send path. The device which I used is mass storage.
I'am using linux kernel 2.6.15.

After virtualization, once the file copy starts from device to pc each
usbip packet carries payload of 64K.

I'am allocating this 64K buffer through __get_free_pages() (with order
4) and assigning
the buffer pointer to urb. After completion of URB i'am trying to send
this buffer page by page
by using tcp_sendpage instead of calling kernel_sendmsg(), this is to
avoid copy which is
done in the TCP send path.

By doing this way it is able to send the buffer successfully, but I'am
not finding the way to free
this buffer. This copy continues until the entire memory is consumed.

who will free this buffer?

1) If i call free_pages for entire 64K right after tcp_sendpage (i.e
after sending all the pages, 64K). then observed
the Kernel panic. It is obvious that the tcp core is not yet finished its job.

2) TCP core is also not freeing these pages.

This might be because, I allocated 64K buffer at once and trying to
free it page by page.

I need some help to resolve this issue.

Performance wise there is a huge jump in throughput.

Thanks,
Vinai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/