On Thu, 10 Aug 2006 13:03:43 +0100, Ian Griffiths <[EMAIL PROTECTED]> wrote:
>Doesn't the capture just refer to the WSABUF structures themselves, and >not the buffers they describe? That's what I've always assumed, and that's how I've always programmed for it--the assumption that the buffers need to remain stable until the completion function is called or the synchronization object is signalled. This, of course, will work regardless of whether the provider is supposed to make a copy of the buffers or not... Then there's the possibility that the provider doesn't do the same thing as documented in WSASend. Here's some quotes on the WSASend documentation: When describing the WSABUF parameter: "This array must remain valid for the duration of the send operation.". "The array of WSABUF structures pointed to by the lpBuffers parameter is transient.", "If this operation is completed in an overlapped manner, it is the service provider's responsibility to capture these WSABUF structures before returning from this call. This enables applications to build stack-based WSABUF arrays." Some quotes where it's unclear what buffer they're referring to: "A completion indication will occur, invoking the completion of a routine or setting of an event object, when the buffer(s) have been consumed by the transport.", "Data is copied from the buffer(s) into the transport's buffer.", in nonoverlapped usage, and "If the socket is nonblocking and stream oriented, and there is not sufficient space in the transport's buffer, WSASend will return with only part of the application's buffers having been consumed.". While it's not overly clear, assuming the data pointed to in the WSABUF are not copied is the safest bet. With respect to Socket.BeginSend(); upon closer inspection it appears it doesn't make a copy of data it is given; it just pins the buffer it is given and creates the WSABUF blob for each operation during creation of the async operation object. This seems to support WSABUF is copied, but the data pointed to in the WSABUF are not... > >While it has been about 10 years since I wrote network device drivers >for a living, back then it was very definitely the case that network >cards would work directly with user buffers. (It was technically >possible to create a driver that made a copy, and some very simple and >cheap network cards might require that. But this was best avoided as the >perf tends to be really bad when you do that.) > >So I'd be very surprised if the actual buffers themselves are being >copied. I'm pretty sure you'll find it's just the WSABUF structures that >are copied. (And they might not actually be copied as such - it's just >that the service provider needs to retain all the information they >contain. It might do this by incorporating that data into its internal >data structures rather than copying the WSABUFs themselves.) > > >By the way, there was some talk of cache locality of reference earlier. >One thing worth bearing in mind is that network transmit and receive >operations will end up flushing the relevant buffers out of cache >anyway. In order for the network card to be able to transmit the >contents of a buffer, those contents need to have been written out to >main memory - your network card can't see inside your CPU cache! And >when a receive occurs, the driver has to inform the OS memory manager >that the contents of the buffer have just been modified and that any >cached data held by the CPU is now out of date. > >So you might not see much benefit from locality of reference here. > >(Although there's one case you might: if a buffer that's just been used >for a read is then recycled for a write, then depending on the access >patterns used to write the data, that might reduce the cache chatter a >little. Also, if your buffer pool is large enough you might be able to >reduce working set size under low load by using a stack. So it might >still be worth it. But be prepared for relatively disappointing >results...) =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
