[openib-general] How about ib_send_page() ?

[Vivek Kashyap]

On Tue, 7 Jun 2005, Michael Krause wrote:

> At 09:28 AM 6/7/2005, Fab Tillier wrote:
> > > From: Roland Dreier [mailto:roland at topspin.com]
> > > Sent: Tuesday, June 07, 2005 8:38 AM
> > >
> > >     Michael> Why not just use the IETF draft for RC / UC based IP over
> > >     Michael> IB and not worry about creating something new?
> > >
> > > I think we've come full circle.  The original post was a suggestion on
> > > how to handle the fact the the connected-mode IPoIB draft requires a
> > > network stack to deal with different MTUs for different destinations
> > > on the same logical link.

Yes, the ipoib wg opinion is that a node should be able to communicate in
any IB mode. (I've had to implement such a setup for tokenring in the past
- e.g. if the peer was on a ring with smaller MTU ).

I beleive this is an issue that needs furhter discussion on the ipoverib
discussion list in ietf. Would you restart the discussion there? We can
update the draft as needed after a consensus is reached in the wg.

> >
> >That's right - by implementing IP segmentation in the IPoIB driver when going
> >over UD, the driver could expose a single MTU to the network stack, thereby
> >removing all the issues related to having per-endpoint MTUs.
> >
> >Keeping a 2K MTU for RC mode doesn't really take advantage of IB's RC
> >capabilities.  I'd probably target 64K as the MTU.
>
> The draft should state a minimum for all RC / UC which should be the TCP
> MSS.  Whether one does SAR over a UD endpoint independent of the underlying
> physical MTU can be done but it should not require end-to-end understanding
> of the operation, i.e. the send side tells its local that the TCP MSS is X
> while the receive side only posts 2-4 KB buffers.  This has been done over
> Ethernet for years.
>
> Mike

I suggest we move this discussion to ipoverib at ietf.org (can continue to cc
this list) to involve all since there have been suggestions for draft update.


Vivek
__

Vivek Kashyap
Linux Technology Center, IBM