Subject: [Ipoverib] IPoIB-RC and Checksums

From: "Yaron Haviv" <[email-masked]>
Date: Thu, 18 Nov 2004 22:18:25 +0200

In GbE usually the NIC Tx Segmentation (large send) capability comes
hand in hand with Checksum offload for greater efficiency (and zero
copy)

On UD we decided not to address checksum offloading, since we cannot
guarantee that the node will not forward an un-checked packet 

Where as in RC we can have examples of devices that can guarantee
checksum 
One example is an IB-IP gateway that always checksum outgoing and
incoming packets, and can act as a remote IP NIC to the Host  

I suggest we include a checksum option in the CM Exchange 
Where a node can request that its peer will not checksum the packet for
it
And also signal that he sends packets that are already checked 
That can help improve performance of IPoIB RC

P.S. another note, we discussed in IETF was that we may want to
mention/suggest (not mandate) use of SRQ for IPoIB-RC in order to
preserve memory 

Yaron

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: Michael Krause <[email-masked]>
Date: Thu, 18 Nov 2004 14:50:50 -0800

At 12:18 PM 11/18/2004, Yaron Haviv wrote:
>checksum One example is an IB-IP gateway that always checksum outgoing and
>I suggest we include a checksum option in the CM Exchange  Where a node 
>can request that its peer will not checksum the packet for it And also 
>signal that he sends packets that are already checked  That can help 
>improve performance of IPoIB RC
>

I remain opposed to disabling checksums under any circumstances.  I do not 
believe there is a method to guarantee that a packet will not be routed by 
higher layers within the network stack without sticking one's nose way into 
the packet.  There is nothing that precludes an IB HCA from providing 
checksum off-load today through a private interface much as what is done 
with Ethernet today.   It isn't hard and presents no interoperability 
issues as it is a local optimization.  Attempting to do this as an 
optimization between endnode pairs makes this more complex and requires 
knowledge that may not be available between all combinations of endnode pairs.

Mike

---

From: Bill Strahm <[email-masked]>
Date: Thu, 18 Nov 2004 15:10:56 -0800

Let me try to be clear with my understanding of the position of the
IESG.

Not sending IP/TCP header checksums in an IP packet is a non-starter.

Using checksum offload technologies to accelerate these computations is
one thing, sending the packets with a checksum value of 0 and not
checking on receive is another.

I talked with Allison Mankin in Washington D.C. and she was terrified of
"raw" IB packets (ie. RC/UD) getting out on the internet and messing
things up because there aren't congestion controls built into these
protocols that will behave correctly with IP.

I would caution the group in considering removing checksumming from
packets when it is relatively cheap for hardware to be added to
HCA/HBA's that can calculate the checksum before sending it on the wire.

Some comments inline.
Bill

> guarantee that the node will not forward an un-checked packet 
I do not believe either the IEEE or the IETF have ever addressed
checksum offloading.  I am not sure that there is a protocol piece to do
here - it is an implementation issue between the OS and the hardware.

> incoming packets, and can act as a remote IP NIC to the Host  
Here you are talking about a different device.  And again - I am not
sure that there is an IETF standard here.  Much like the IETF does not
want to standardize iSER over IB (with no IP in the middle) I don't
believe it wants to standardize Host/OS <--> NIC interactions.  The
device you are proposing does not have (require might be a better word
here) an IP interaction between the HOST and an IP ofload NIC (I have
heard of several implementations of things called a VNIC or virtual NIC)

I do not believe there is a proposal to standardize a VNIC protocol -
and if there was, I do not believe that this is IETF work.
> That can help improve performance of IPoIB RC
I believe this is a non-starter in the IESG - Margarete, can you confirm
this ?

> mention/suggest (not mandate) use of SRQ for IPoIB-RC in order to
Again, in the spirit of Wire protocol vs. Implementation.  I think this
is an implementation issue that will not change wire protocols at all.
Is there a point where using SRQ vs. Not Using SRQ would have to change
the wire protocol ?

If not - lets not say anything.
If there is - I would be very interested in understanding.

Bill