All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Tucker <tom@opengridcomputing.com>
To: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
Cc: linux-nfs <linux-nfs@vger.kernel.org>,
	Bruce Fields <bfields@fieldses.org>
Subject: Re: [PATCH] svcrdma: Limit ORD based on client's advertised IRD
Date: Mon, 19 May 2008 13:54:22 -0500	[thread overview]
Message-ID: <1211223262.31725.58.camel@trinity.ogc.int> (raw)
In-Reply-To: <RTPCLUEXC1-PRD4mG0E00000117-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>


On Mon, 2008-05-19 at 14:34 -0400, Talpey, Thomas wrote:
> At 02:32 PM 5/19/2008, Tom Tucker wrote:
> >> Well, technically the iWARP connection manager *currently* does not
> >> exchange these values. I think the comment would be more accurate
> >> if it said "in the absence of"...
> >
> >I'm not sure it really has anything to do with where it is implemented.
> 
> That wasn't my point - I meant, in the absence of information what the
> peer's maximum might be, the server has to make something up. But, future
> iwarp cm's could pass it.
> 
> What value bubbles up in this field from current iWARP connections? Is
> it total garbage, or at least, recognizably useless (-1)?

For iWARP it is currently the local device's max. When iWARP (hopefully)
gets a standard for this -- it will be the remote peer's IRD. This code
won't need to change.

> 
> >> >-static void handle_connect_req(struct rdma_cm_id *new_cma_id)
> >> >+static void handle_connect_req(struct rdma_cm_id *new_cma_id, u8 
> >client_ird)
> >> 
> >> While "u8" might be the limit of the implementations today, wouldn't "int" be
> >> easier to understand, and more portable?
> >> 
> >
> >I think that 'int' might provoke the "wrath of Chuck". Unsigned
> >something else --
> 
> Okay, well if not "int", then at least some type which is not a specific
> storage size. u{8,16,32} etc should be reserved for describing hardware
> and on-wire stuff, and handled as native when used locally.
> 
> Tom.


      parent reply	other threads:[~2008-05-19 18:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-19 16:34 [PATCH] svcrdma: Limit ORD based on client's advertised IRD Tom Tucker
     [not found] ` <1211214842.31725.38.camel-SMNkleLxa3ZimH42XvhXlA@public.gmane.org>
2008-05-19 17:17   ` Talpey, Thomas
     [not found]     ` <RTPCLUEXC1-PRD1q4gt00000114-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-05-19 17:39       ` J. Bruce Fields
2008-05-19 18:32       ` Tom Tucker
     [not found]       ` <1211221933.31725.56.camel-SMNkleLxa3ZimH42XvhXlA@public.gmane.org>
2008-05-19 18:34         ` Talpey, Thomas
     [not found]           ` <RTPCLUEXC1-PRD4mG0E00000117-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-05-19 18:54             ` Tom Tucker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1211223262.31725.58.camel@trinity.ogc.int \
    --to=tom@opengridcomputing.com \
    --cc=Thomas.Talpey@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.