<html>
<body>
<font size=3><br>
Just a bit of history...<br><br>
When the idea or argument was first presented within the IETF that an IB
fabric is inherently reliable and therefore one could disable checksum
calculations to improve performance, it was soundly rejected by the hum
in the room. The primary arguments were:<br><br>
- Checksums are required per the end-to-end argument. <br><br>
- Any node on a subnet can act as a gateway to another
subnet. Many of these gateways are implemented using today's
OS network stacks and should not require modification to operate for IB
since all other layer 2 interconnects require no such
modifications.<br><br>
While it might be possible to do something, the consensus was if
performance is the objective, then implement the same checksum off-load
techniques on IB HCA / TCA hardware. That was deemed far more
practical and more likely compliant with customer expectations than
trying to modify the network stacks as well as the sacrosanct end-to-end
argument. I would be very leery of attempting to push this into the
industry or customer base. Vendors already face challenges in
selling IB outside of HPC workloads and adding more fuel to the fire will
only increase that challenge. Please keep in mind that a RNIC based
solution does not require such added complexity and our preference to
date has been to keep these technologies as close to functional parity as
possible.<br><br>
Mike<br><br>
<br><br>
At 01:02 PM 9/4/2007, James Lentini wrote:<br><br>
<br>
<blockquote type=cite class=cite cite="">On Tue, 4 Sep 2007, Michael S.
Tsirkin wrote:<br><br>
> > Quoting James Lentini <jlentini@netapp.com>:<br>
> > Subject: Re: [PATCHv2] IB/ipoib: S/G and HW checksum
support<br>
> > <br>
> > <br>
> > <br>
> > On Tue, 4 Sep 2007, Michael S. Tsirkin wrote:<br>
> > <br>
> > > Add module option hw_csum: when set, IPoIB will report
S/G<br>
> > > support, and rely on hardware end-to-end transport
checksum (ICRC)<br>
> > > instead of software-level protocol checksums.<br>
> > <br>
> > The purpose of this option would be clearer if the parameter
name were <br>
> > "omit_csum". Calling this "HW checksum"
support is misleading because <br>
> > the term is already used to describe network adapters that
calculate <br>
> > TCP/IP checksums in hardware. I realize that you are using the
HW <br>
> > checksum infrastructure to implement this, but it is really not
the <br>
> > same thing.<br>
> <br>
> Another reason is that I declare HW_CSUM in the netdev<br>
> feature list. Yea, someone might get confused,<br>
> but "omit checksum" is misleading, too, and is likely
to<br>
> scare users away from the feature: the need for end-to-end
checksum<br>
> is a widely recognised requirement. <br><br>
I agree. Since this isn't an end-to-end checksum, I recommend that be
<br>
made clear to the user.<br><br>
> So I don't have a better name. Hopefully modinfo documents the <br>
> option well enough.<br>
> <br>
> > > Since this will not inter-operate with older IPoIB
modules, this <br>
> > > option is off by default.<br>
> > > <br>
> > > Signed-off-by: Michael S. Tsirkin
<mst@mellanox.co.il><br>
> > <br>
> > Does the S/G support need to be tied to the checksum
changes?<br><br>
Can you separate the S/G support and checksum changes into different
<br>
patches?<br>
_______________________________________________<br>
general mailing list<br>
general@lists.openfabrics.org<br>
<a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general" eudora="autourl">
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</a><br><br>
To unsubscribe, please visit
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">
http://openib.org/mailman/listinfo/openib-general</a>
</font></blockquote></body>
</html>