Re: [PATCH v2 1/8] ib_mad: incoming sminfo SMPs gets discarded if no process_mad function is registered

[Knut Omang]

On Fri, 2016-09-16 at 13:28 -0700, Santosh Shilimkar wrote:
> On 9/16/2016 11:31 AM, Knut Omang wrote:
> > From: Dag Moxnes 
> >
> > The process_mad function is an optional IB driver entry point
> > allows a driver to intercept or modify MAD traffic.
> >
> > This fix allows MAD traffic to flow down to the device also
> > when MAD traffic is completely handled by the device and
> > no process_mad function is provided.
> >
> > SIF, the new Oracle Infiniband HCA, is the first HCA
> > where the device itself makes all decision wrt MAD processing.
> > Up till now devices either supports MAD, and do then
> > implement the process_mad entry point, or do not
> > support MAD at all, and then do not implement process_mad.
> >
> > SIF introduces a 3rd case: Supports MAD
> > but do not terminate any MAD requests in the driver.
> > This case is not handled well by the current code.
> >
> > The problem is that the handle_outgoing_dr_smp function
> > has an implicit assumption that some packets are handled
> > by the process_mad function itself.
> >
> > There is no way to provide return values from the process_mad
> > function that ensures that packets are always forwarded to the device,
> > so the only viable solution without breaking the API
> > seems to be to not implement process_mad.
> 
> No SOBs ?

is unfortunately recurring for several of the patches due to a missing -ns to 
format-patch.
Will fix,

Thanks,
Knut

Re: [PATCH v2 1/8] ib_mad: incoming sminfo SMPs gets discarded if no process_mad function is registered

[Knut Omang]

On Fri, 2016-09-16 at 13:28 -0700, Santosh Shilimkar wrote:
> On 9/16/2016 11:31 AM, Knut Omang wrote:
> > From: Dag Moxnes 
> >
> > The process_mad function is an optional IB driver entry point
> > allows a driver to intercept or modify MAD traffic.
> >
> > This fix allows MAD traffic to flow down to the device also
> > when MAD traffic is completely handled by the device and
> > no process_mad function is provided.
> >
> > SIF, the new Oracle Infiniband HCA, is the first HCA
> > where the device itself makes all decision wrt MAD processing.
> > Up till now devices either supports MAD, and do then
> > implement the process_mad entry point, or do not
> > support MAD at all, and then do not implement process_mad.
> >
> > SIF introduces a 3rd case: Supports MAD
> > but do not terminate any MAD requests in the driver.
> > This case is not handled well by the current code.
> >
> > The problem is that the handle_outgoing_dr_smp function
> > has an implicit assumption that some packets are handled
> > by the process_mad function itself.
> >
> > There is no way to provide return values from the process_mad
> > function that ensures that packets are always forwarded to the device,
> > so the only viable solution without breaking the API
> > seems to be to not implement process_mad.
> 
> No SOBs ?

is unfortunately recurring for several of the patches due to a missing -ns to 
format-patch.
Will fix,

Thanks,
Knut

Re: [PATCH v2 1/8] ib_mad: incoming sminfo SMPs gets discarded if no process_mad function is registered

[Santosh Shilimkar]

On 9/16/2016 11:31 AM, Knut Omang wrote:

From: Dag Moxnes 

The process_mad function is an optional IB driver entry point
allows a driver to intercept or modify MAD traffic.

This fix allows MAD traffic to flow down to the device also
when MAD traffic is completely handled by the device and
no process_mad function is provided.

SIF, the new Oracle Infiniband HCA, is the first HCA
where the device itself makes all decision wrt MAD processing.
Up till now devices either supports MAD, and do then
implement the process_mad entry point, or do not
support MAD at all, and then do not implement process_mad.

SIF introduces a 3rd case: Supports MAD
but do not terminate any MAD requests in the driver.
This case is not handled well by the current code.

The problem is that the handle_outgoing_dr_smp function
has an implicit assumption that some packets are handled
by the process_mad function itself.

There is no way to provide return values from the process_mad
function that ensures that packets are always forwarded to the device,
so the only viable solution without breaking the API
seems to be to not implement process_mad.


No SOBs ?

Re: [PATCH v2 1/8] ib_mad: incoming sminfo SMPs gets discarded if no process_mad function is registered

[Santosh Shilimkar]

On 9/16/2016 11:31 AM, Knut Omang wrote:

From: Dag Moxnes 

The process_mad function is an optional IB driver entry point
allows a driver to intercept or modify MAD traffic.

This fix allows MAD traffic to flow down to the device also
when MAD traffic is completely handled by the device and
no process_mad function is provided.

SIF, the new Oracle Infiniband HCA, is the first HCA
where the device itself makes all decision wrt MAD processing.
Up till now devices either supports MAD, and do then
implement the process_mad entry point, or do not
support MAD at all, and then do not implement process_mad.

SIF introduces a 3rd case: Supports MAD
but do not terminate any MAD requests in the driver.
This case is not handled well by the current code.

The problem is that the handle_outgoing_dr_smp function
has an implicit assumption that some packets are handled
by the process_mad function itself.

There is no way to provide return values from the process_mad
function that ensures that packets are always forwarded to the device,
so the only viable solution without breaking the API
seems to be to not implement process_mad.


No SOBs ?