Re: [PATCH] IB/ipoib: CSUM support in connected mode

[Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>]

On Thu, Jul 30, 2015 at 03:00:18PM -0600, Jason Gunthorpe wrote:
> On Thu, Jul 30, 2015 at 11:46:36PM +0300, Yuval Shaia wrote:
> > On Thu, Jul 30, 2015 at 11:15:38AM -0600, Jason Gunthorpe wrote:
> > > On Thu, Jul 30, 2015 at 11:51:12AM -0400, Doug Ledford wrote:
> > > 
> > > > In its current state, I have my doubts about this patch.  However, it
> > > > seems to me that this should be relatively easy to fix in such a way
> > > > that you get 90%+ of the performance benefit, and can turn it on by
> > > > default, and we don't cause any problems.
> > > 
> > > The best way to implement this is to leverage all the checksum
> > > offload work people did for virtualization.
> > > 
> > > Forward the checksum offload status through the RC connection and
> > > recover it on the other side.
> > The current approach is to utilize IPoIB's private-data to exchange this
> > information.
> 
> You need private-data exchange to negotiate the feature.
> 
> The feature should be a per-packet csum status header.
> 
> When sending a skb that is already fully csumed the receiver sets
> CHECKSUM_UNNECESSARY.
> 
> When sending a skb that has CHECKSUM_PARTIAL then the
> receiver needs to call skb_partial_csum_set.
> 
> Look at how something like VIRTIO_NET_HDR_F_NEEDS_CSUM works and copy
> that scheme.
Correct me if i'm wrong here but isn't this protocol assume both parties
are aware of this special header?
My case is a bit different, driver must support backward computability in a
way that peer maybe a driver that do not support this feature and expect
packet to be full checksummed.
> 
> DO NOT EVER set CHECKSUM_UNNECESSARY on packets that do not have valid
> csums - that breaks the net stack.
The entire idea here is to fake csum offload so how would i tell the stack
not to run csum on incoming packet?
> 
> Yes, you need to add a header to all packets to support this scheme,
> that is what the private-data negotiation is for.
> 
> While you are at it, I'd make room for something like
> VIRTIO_NET_HDR_GSO_* in the RC protocol too. Implementing GSO
> forwarding is probably another big performance win.
If i understood you correctly and you mean exchange of
"driver-capabilities", then yes, it is there with the extends of
ipoib_cm_data structure.
> 
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html