All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>
To: Christopher Mitchell
	<christopher-1z5WdJkP5Frk1uMJSBkQmQ@public.gmane.org>,
	"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Rare Duplicate Completions
Date: Mon, 07 Apr 2014 18:01:46 -0700	[thread overview]
Message-ID: <53434A7A.7000504@acm.org> (raw)
In-Reply-To: <CAPb9-SF6OS3xabKMJdT2Fe32=O1nOhS5y3Ng3ySQG3KOHvcV=Q@mail.gmail.com>

On 4/04/2014 10:00, Christopher Mitchell wrote:
> I am working on building a distributed Infiniband application, testing
> using Mellanox Connect-X HCAs. In very rare cases, perhaps once in a
> few million operations, I appear to be receiving duplicate completions
> or incorrect completions. For instance, I'll send out an RDMA request
> and receive a completion for a Verb message response I had just
> handled, or send a Verb message request and receive a duplicate Verb
> message completion.. Needless to say, this is introducing instability
> in my application. Does anyone have experience with a bug like this,
> or am I encountering some arcane issue in how I'm manipulating the
> HCA? I'd be more than happy to furnish relevant sections of code to
> help nail down the issue.

Hello Christopher,

In e.g. the SCST SRP target driver there is code present that checks for 
duplicate and/or missing completions. Although this code is being used 
intensively I have not yet seen any error messages being logged by the 
code that verifies completions. Note: something that is nontrivial in 
the RDMA API and that you might already be aware of is that even for 
non-signaled work requests a completion is delivered if that work 
request fails. If these non-signaled work requests do not have a unique 
wr_id error completions for these requests might be misinterpret as 
duplicate completions.

Bart.
--
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

  reply	other threads:[~2014-04-08  1:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-04 17:00 Rare Duplicate Completions Christopher Mitchell
2014-04-08  1:01 ` Bart Van Assche [this message]
     [not found]   ` <CAPb9-SEvrWWxWbjSDz5iVP16aRTbDd4tg-TN_af0ecB0o3m1Sw@mail.gmail.com>
     [not found]     ` <CAPb9-SEvrWWxWbjSDz5iVP16aRTbDd4tg-TN_af0ecB0o3m1Sw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-10 21:43       ` Christopher Mitchell

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=53434A7A.7000504@acm.org \
    --to=bvanassche-hinycgiudog@public.gmane.org \
    --cc=christopher-1z5WdJkP5Frk1uMJSBkQmQ@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.