[prev in list] [next in list] [prev in thread] [next in thread]
List: opensolaris-networking-discuss
Subject: Re: [networking-discuss] What is zero-copy safe
From: "Sumit Gupta" <sumitg () Brocade ! com>
Date: 2008-12-18 17:20:24
Message-ID: 57AC2FA1761300418C7AB8F3EA493C97024BA03E () HQ-EXCH-5 ! corp ! brocade ! com
[Download RAW message or body]
--===============0744474805==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C96135.09E664D8"
This is a multi-part message in MIME format.
Thanks Paul.
Sumit
-----Original Message-----
From: Paul Durrant [mailto:pdurrant@gmail.com]
Sent: Thu 12/18/2008 2:21 AM
To: Sumit Gupta
Cc: networking-discuss@opensolaris.org
Subject: Re: [networking-discuss] What is zero-copy safe
Sumit Gupta wrote:
> Inside gld_mac_info->gldm_capabilities, there is a flag defined as
> GLD_CAP_ZEROCOPY. Doing some research, it seem to map to
> DL_CAPAB_ZEROCOPY which means that the NIC driver is zero copy safe.
> What is the meaning of zero copy safe ?
>
The meaning may have changed, but when this capability was introduced
the meaning of it was that the driver guaranteed to complete transmits
in a timely fashion.
The problem is that if you do a sendfile() and the network stack simply
maps the file and wraps it in a set of STREAMS blocks then it must
obviously hold a reference on that file; and if a driver holds onto the
STREAMS blocks on its transmit side then it is essentally holding that
file to ransom. So, if the driver exports the GLD_CAP_ZEROCOPY
capability then it is essentially declaring that it is not going to hold
onto transmitted blocks for an unreasonable amount of time (i.e.
significantly longer than it takes to put them on the wire) and thus
will not hold a file to ransom in this way.
Paul
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [networking-discuss] What is zero-copy safe</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>Thanks Paul.<BR>
Sumit<BR>
<BR>
-----Original Message-----<BR>
From: Paul Durrant [<A HREF="mailto:pdurrant@gmail.com">mailto:pdurrant@gmail.com</A>]<BR>
Sent: Thu 12/18/2008 2:21 AM<BR>
To: Sumit Gupta<BR>
Cc: networking-discuss@opensolaris.org<BR>
Subject: Re: [networking-discuss] What is zero-copy safe<BR>
<BR>
Sumit Gupta wrote:<BR>
> Inside gld_mac_info->gldm_capabilities, there is a flag defined as<BR>
> GLD_CAP_ZEROCOPY. Doing some research, it seem to map to<BR>
> DL_CAPAB_ZEROCOPY which means that the NIC driver is zero copy safe.<BR>
> What is the meaning of zero copy safe ?<BR>
><BR>
<BR>
The meaning may have changed, but when this capability was introduced<BR>
the meaning of it was that the driver guaranteed to complete transmits<BR>
in a timely fashion.<BR>
The problem is that if you do a sendfile() and the network stack simply<BR>
maps the file and wraps it in a set of STREAMS blocks then it must<BR>
obviously hold a reference on that file; and if a driver holds onto the<BR>
STREAMS blocks on its transmit side then it is essentally holding that<BR>
file to ransom. So, if the driver exports the GLD_CAP_ZEROCOPY<BR>
capability then it is essentially declaring that it is not going to hold<BR>
onto transmitted blocks for an unreasonable amount of time (i.e.<BR>
significantly longer than it takes to put them on the wire) and thus<BR>
will not hold a file to ransom in this way.<BR>
<BR>
Paul<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
--===============0744474805==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic