I had actually already started working on a set of patches for this, but
I've incorporated some of your work.

There were problems with your patches:

* The limits on messages were global, not per-user.  This could cause
  unfairness in the interface.

* The counts were on the BMC, not on the interface.  The interface is
  the right place to put them, as that's where the messages flow
  through, and it's easier to do.

* Going through all the messages to get the count is kind of inefficient
  to do on a per-send basis.  Keep a count instead.

* The ability to flush messages is a no-go.  The IPMI driver guarantees
  responses and internal kernel users (and external users) rely on that
  property.  A flush could break the watchdog or ACPI.  The messages
  will just have to time out.

This is my proposal for your review.

Thanks,

-corey

On 2022/3/30 02:33, minyard@acm.org wrote:
> I had actually already started working on a set of patches for this, but
> I've incorporated some of your work.
> 
> There were problems with your patches:
> 
> * The limits on messages were global, not per-user.  This could cause
>    unfairness in the interface.
> 
> * The counts were on the BMC, not on the interface.  The interface is
>    the right place to put them, as that's where the messages flow
>    through, and it's easier to do.
> 
> * Going through all the messages to get the count is kind of inefficient
>    to do on a per-send basis.  Keep a count instead.
> 
> * The ability to flush messages is a no-go.  The IPMI driver guarantees
>    responses and internal kernel users (and external users) rely on that
>    property.  A flush could break the watchdog or ACPI.  The messages
>    will just have to time out.
> 
> This is my proposal for your review.
> 
> Thanks,
> 
> -corey

Hi Corey:

Thanks, My intention is to provide a debug method, it is not perfect.

I try to use your patch in cluster directly.

If the problem no longer occurs, there is no need to cleanup the messages.

--
Chen Guanqiao