[ofa-general] Receiving Unknown packets at regular interval

[Hal Rosenstock]

Sumit,

On Wed, 2008-05-21 at 13:03 +0530, Sumit Gaur - Sun Microsystem wrote:
> Hi Hal/Yevgeny,
> 	Looks like I am more confusing you then a clearcut question so I am giving you 
> my implementation detail in simple steps:-
> 
> 1) I am calling madrpc_init(ca, ca_port, mgmt_classes, 4); for given ca and 
> ca_port to register following four classes to OFED library
> 
> {IB_SMI_CLASS,IB_SMI_DIRECT_CLASS, IB_SA_CLASS, IB_PERFORMANCE_CLASS};
> 
> 2) After registration I am opening two separate independent threads one for 
> sending MADs and another for receiving it.
> 
> 3) Sending thread send MADs using
> 
> umad_send(port_id, class_agents[mgtclass],&sndbuf, length, timeout, 0);
> 
> 4) Receiver thread receive MADs using  mad_receive(0, -1); function.
> 
> 5) I am sending SMP and GMP packets at regular time interval and keep receiving 
> response on receiver thread properly. But sometime I am receiving some extra 
> packets with *unknown tids*(tid I have never send). e.g.
> 
> Response TID2 = 0x000000006701869b , BaseVersion = 1, MgmtClass=129,
> ClassVersion=1, R_Method=129, ClassSpecific=1, Status=128, AttributeID=4352
> (All are decimal representation)
> 
> 		Now question comes how I could filter these extra packets. These  incoming 
> packets could be response SM sends while sweeping the subnet(As pointed out by 
> Yevgeny). Is these any unique MAD field that could be checked for SM response. 
> OR this could not be filtered then i will change logic in application.

Not knowing what SMPs you are sending in your application, it's hard to
be more specific. You can filter on class and attribute ID (assuming
these attribute IDs per class) are distinct. Another approach would be
able to filter on transaction ID as the upper 32 bits should be
different (on a per underlying fd basis). This approach is simpler and
not rely on non overlapping subsets of attributes.

I was also trying to say that I'm not sure you should be seeing these
packets (and I don't think your application should need to do this). The
current filtering appears to not be working for some unknown reason in
your environment.

Hopefully this makes more sense. Sorry for all the confusion.

-- Hal

> Thanks and Regards
> sumit
> 
> 
> 
> Hal Rosenstock wrote:
> > On Tue, 2008-05-20 at 11:44 +0530, Sumit Gaur - Sun Microsystem wrote:
> > 
> >>How we can identify and filter these incoming SM packets in application from 
> >>the regular responses.
> > 
> > 
> > I'm surprised that it's working this way; that SM responses are getting
> > into your application as they _should_ have a different transaction ID
> > per the following.
> yes they have different TID.
> > 
> >>From the kernel Documentation/infiniband/user_mad.txt:
> > 
> > Transaction IDs
> > 
> >   Users of the umad devices can use the lower 32 bits of the
> >   transaction ID field (that is, the least significant half of the
> >   field in network byte order) in MADs being sent to match
> >   request/response pairs.  The upper 32 bits are reserved for use by
> >   the kernel and will be overwritten before a MAD is sent.
> > 
> > Is the same fd being used by OpenSM and your application somehow or you
> > are not using OpenSM and your SM overlaps with this ?
> I am not using OpenSM, I am directing calling umad libraries.
> > 
> > -- Hal
> >