Project

General

Profile

Bug #12439

mlxcx send rings can overflow

Added by Paul Winder 10 months ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
driver - device drivers
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

If the send queue is the same size (or smaller) than its paired completion queue, it is likely to overflow and become non-functionaL

A send mblk can occupy multiple send queue entries (WQEBBs), but will use a single completion queue entry when finished. To guard against this, we need to do accounting for both the completion and send queue entries, and not submit any more packets when either is beyond their threshold.


Related issues

Related to illumos gate - Bug #12383: Slow down and lock up in mlxcx receive interrupt pathClosedPaul Winder

Actions
#1

Updated by Paul Winder 10 months ago

  • Related to Bug #12383: Slow down and lock up in mlxcx receive interrupt path added
#2

Updated by Paul Winder 10 months ago

  • Subject changed from mlxcx send and receive rings can overflow to mlxcx send rings can overflow
#3

Updated by Paul Winder 10 months ago

  • Description updated (diff)
#4

Updated by Electric Monk 10 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 80 to 100

git commit 22d052287ba7ed169757650e2eec25fedbae163a

commit  22d052287ba7ed169757650e2eec25fedbae163a
Author: Paul Winder <pwinder@racktopsystems.com>
Date:   2020-04-14T15:40:07.000Z

    12383 Slow down and lock up in mlxcx receive interrupt path
    12438 mlxcx should pass receive messages to mac layer more frequently
    12439 mlxcx send rings can overflow
    12440 mlxcx should not block in the send path
    12441 mlxcx default queue sizes are a bit on the small size
    Reviewed by: Garrett D'Amore <garrett@damore.org>
    Reviewed by: Andy Stormont <astormont@racktopsystems.com>
    Reviewed by: Igor Kozhukhov <igor@dilos.org>
    Reviewed by: Robert Mustacchi <rm@fingolfin.org>
    Approved by: Garrett D'Amore <garrett@damore.org>

Also available in: Atom PDF