----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41158/#review109644 -----------------------------------------------------------
This is more like a question: do we need to turn off tx side as well? - Jie Yu On Dec. 9, 2015, 11:15 p.m., Cong Wang wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/41158/ > ----------------------------------------------------------- > > (Updated Dec. 9, 2015, 11:15 p.m.) > > > Review request for mesos, Ian Downes and Jie Yu. > > > Bugs: MESOS-4105 > https://issues.apache.org/jira/browse/MESOS-4105 > > > Repository: mesos > > > Description > ------- > > We noticed that in some cases we delivered some corrupt packets to > applications running in our containers. This is clearly wrong. > > Here is what happens: > > 1) We receive a corrupt packet externally > 2) The hardware driver is able to checksum it and notices it has a bad > checksum > 3) The driver delivers this packet anyway to wait for TCP layer to checksum > it again and then drop it > 4) This packet is moved to a veth interface because it is for a container > 5) Both sides of the veth pair have RX checksum offloading by default > 6) The veth_xmit() marks the packet's checksum as UNNECESSARY since its peer > device has rx checksum offloading > 7) Packet is moved into the container TCP/IP stack > 8) TCP layer is not going to checksum it since it is not necessary > 9) The packet gets delivered to application layer > > > Diffs > ----- > > src/slave/containerizer/mesos/isolators/network/port_mapping.cpp > 89bb36f936417de8169a2442729fbd7c9d60acb7 > > Diff: https://reviews.apache.org/r/41158/diff/ > > > Testing > ------- > > 1) Turn rx checksum off manually and the bug is gone > 2) Test this patch and verify rx checksum is turned off as expected. > 3) I don't see any noticable performance issue after turning this off > > > Thanks, > > Cong Wang > >
