There are/may be several other bugs with the qemu pcnet emulation. I do not know if there is any other serialization outside of this code, but if both a transmit and a receive operation were to be performed at the same time on different cpus, since the same buffer is used for both transmit and receive, that would also cause data corruption. Does anyone else know how this is prevented, or is this another source of corruption? Another thing I noticed, that will reduce throughput if corrected, is that the wrong bit is being examined in the receive path, to determine if mac level crc should be computed. Right now, the wrong bit is being checked and no mac level crc is being calculated. If the right bit were looked at, mac level crc would need to be computed, slowing down the transfers. However, since no driver cares about the crc right now, since neither Linux or XP complain, could the code to compute the crc be deleted? Maybe just comment that the crc should be computed. Any recommendations? -- Don Fry brazilnut@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Don Fry wrote:> There are/may be several other bugs with the qemu pcnet emulation. I doNot sure if Don mentioned this earlier, but for the benefit of those who might need the context, please see Xen Bugzilla #574/#575.> not know if there is any other serialization outside of this code, but if > both a transmit and a receive operation were to be performed at the same > time on different cpus, since the same buffer is used for both transmit > and receive, that would also cause data corruption. > > Does anyone else know how this is prevented, or is this another source > of corruption? > > Another thing I noticed, that will reduce throughput if corrected, is > that the wrong bit is being examined in the receive path, to determine > if mac level crc should be computed. Right now, the wrong bit is being > checked and no mac level crc is being calculated. If the right bit were > looked at, mac level crc would need to be computed, slowing down the > transfers. However, since no driver cares about the crc right now, > since neither Linux or XP complain, could the code to compute the crc be > deleted? Maybe just comment that the crc should be computed. > > Any recommendations?I''d really like to continue to avoid the CRC computation between domains, but intentionally, this time, in a clean way :). thanks, Nivedita _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 22 Mar 2006, at 01:36, Nivedita Singhvi wrote:>> Another thing I noticed, that will reduce throughput if corrected, is >> that the wrong bit is being examined in the receive path, to determine >> if mac level crc should be computed. Right now, the wrong bit is >> being >> checked and no mac level crc is being calculated. If the right bit >> were >> looked at, mac level crc would need to be computed, slowing down the >> transfers. However, since no driver cares about the crc right now, >> since neither Linux or XP complain, could the code to compute the crc >> be >> deleted? Maybe just comment that the crc should be computed. >> Any recommendations? > > I''d really like to continue to avoid the CRC computation between > domains, but intentionally, this time, in a clean way :).The code should be deleted as the underlying physical transport (e.g., shared memory, physical Ethernet) will ensure link-layer integrity. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel