[openib-general] How about ib_send_page() ?

[Vivek Kashyap]

On 19 May 2005, Hal Rosenstock wrote:

> Hi Vivek,
> 
> On Thu, 2005-05-19 at 12:41, Vivek Kashyap wrote:
> > <snip...>
> > 
> > > 
> > > The most interesting optimization available is implementing the IPoIB
> > > connected mode draft, although I don't think it's as easy as Vivek
> > > indicated -- for example, I'm not sure how to deal with having
> > > different MTUs depending on the destination.
> > 
> > <snip...>
> > 
> > The draft does allow for a negotiation per connection for the implementations
> > that wish to take advantage of it. However, an implementation can by default
> > choose to use a 'connected-mode MTU' e.g. 32K always. It can then, for every 
> > connection choose to, negotiate to this value and if it is not workable fall 
> > back to the UD mode and deny the connection mode. The ARP entries hold the 
> > connected mode flags thereby keeping track of the mode to use per destination. 
> 
> Sounds like there should be an "agreement" on a default connected mode
> MTU or else this will drop down to UD.

Do you mean an administrative CM MTU set across the subnet? It is possible,
though one must be aware of any conflicts depending on the implementations.

See an alternative suggestion I just noted in response to Roland's question.

> 
> I have a couple of clarification questions on 5.1 Per-Connection MTU:
> 
> 1. I presume the Receive MTU is in the first 2 bytes of the private data
> in the CM messages. Is that correct ?

Yes..though I'll relook and make the placement clearer in the next version 
of the draft.

> 
> 2. Also, CM REQ is mentioned for the requester receive MTU. Wouldn't CM
> REP carry the granted receive MTU which is constrained to be the
> requested MTU or less ? So 2 things on this:

No, we don't need a two way handshake. Each side just advertises the maximum
MTU it can handle. It is like TCP MSS. The 

> The I-D says "The private data field MUST carry" the receive MTU. Does
> that include RTUs ?

No, I'd think that we can limit it to REQ. It has been a while since I went
over this -- I'll go over the spec again and post an update if needed.

Vivek

> 
> Thanks.
> 
> -- Hal
> 
> 
>