On 12/20/2015 5:10 AM, Matan Barak wrote:
> On Mon, Dec 14, 2015 at 6:06 PM, Christoph Lameter wrote:
>> On Mon, 14 Dec 2015, Matan Barak wrote:
>>
No idea what the counter is doing. Saw another EXT counter implementation
use 0 so I thought that was fine.
>>>
>>> It seems like a counter
On Mon, Dec 14, 2015 at 6:06 PM, Christoph Lameter wrote:
> On Mon, 14 Dec 2015, Matan Barak wrote:
>
>> > No idea what the counter is doing. Saw another EXT counter implementation
>> > use 0 so I thought that was fine.
>>
>> It seems like a counter index, but I might be wrong though. If it is,
>>
On 12/17/2015 2:21 PM, Christoph Lameter wrote:
> On Thu, 17 Dec 2015, Hal Rosenstock wrote:
>
>>> I thought a port is always supplied since we get the info for a particular
>>> port and the directory only exists if there is a port?
>>
>> Yes, but there is no port (PortSelect) field in ClassPortIn
On Thu, 17 Dec 2015, Hal Rosenstock wrote:
> > I thought a port is always supplied since we get the info for a particular
> > port and the directory only exists if there is a port?
>
> Yes, but there is no port (PortSelect) field in ClassPortInfo attribute
> unlike the PortCounters and PortExtende
On 12/17/2015 1:54 PM, Christoph Lameter wrote:
> On Thu, 17 Dec 2015, Hal Rosenstock wrote:
>> ClassPortInfo is per class not per class per port so need to indicate to
>> get_mad whether a port is supplied or not or conditionalize based on
>> attr ID.
>
> I thought a port is always supplied si
On Thu, 17 Dec 2015, Hal Rosenstock wrote:
> > + * Get a MAD block of data.
>
> Nit: Get PerfMgt MAD block of data
Ok.
> > + * Returns error code or the number of bytes retrieved.
> > + */
> > +static int get_mad(struct ib_device *dev, int port_num, int attr,
>
> Nit: Maybe this is too verbose b
On 12/16/2015 2:34 PM, Christoph Lameter wrote:
> On Wed, 16 Dec 2015, Christoph Lameter wrote:
>
>> DRAFT: This is missing the check if this device supports
>> extended counters.
>
> Found some time and here is the patch with the detection of the extended
> attribute through sending a mad reques
On Wed, 16 Dec 2015, Christoph Lameter wrote:
> DRAFT: This is missing the check if this device supports
> extended counters.
Found some time and here is the patch with the detection of the extended
attribute through sending a mad request. Untested. Got the info on how
to do the proper mad reques
On 12/15/2015 04:46 PM, Doug Ledford wrote:
> On 12/15/2015 04:42 PM, Hal Rosenstock wrote:
>> On 12/15/2015 4:20 PM, Jason Gunthorpe wrote:
The unicast/multicast extended counters are not always supported -
> depends on setting of PerfMgt ClassPortInfo
> CapabilityMask.IsExtendedWidth
On Tue, 15 Dec 2015, Jason Gunthorpe wrote:
> > The unicast/multicast extended counters are not always supported -
> > depends on setting of PerfMgt ClassPortInfo
> > CapabilityMask.IsExtendedWidthSupportedNoIETF (bit 10).
>
> Yes.. certainly this proposed patch needs to account for that and
> con
On Tue, 15 Dec 2015, Doug Ledford wrote:
> On 12/15/2015 04:42 PM, Hal Rosenstock wrote:
> > On 12/15/2015 4:20 PM, Jason Gunthorpe wrote:
> >>> The unicast/multicast extended counters are not always supported -
> depends on setting of PerfMgt ClassPortInfo
> CapabilityMask.IsExtendedWid
On 12/15/2015 04:42 PM, Hal Rosenstock wrote:
> On 12/15/2015 4:20 PM, Jason Gunthorpe wrote:
>>> The unicast/multicast extended counters are not always supported -
depends on setting of PerfMgt ClassPortInfo
CapabilityMask.IsExtendedWidthSupportedNoIETF (bit 10).
>
>> Yes.. certainly th
On 12/15/2015 4:20 PM, Jason Gunthorpe wrote:
>> The unicast/multicast extended counters are not always supported -
>> > depends on setting of PerfMgt ClassPortInfo
>> > CapabilityMask.IsExtendedWidthSupportedNoIETF (bit 10).
> Yes.. certainly this proposed patch needs to account for that and
> co
On Tue, Dec 15, 2015 at 03:01:03PM -0500, Hal Rosenstock wrote:
> > I would agree, from my observation, that the two main byte counters
> > are always available.
>
> The extended packet counts work but I thought there was a PMA with one
> of the extended byte counts wired to 0.
Can't remember
>
On 12/15/2015 2:55 PM, Jason Gunthorpe wrote:
> On Tue, Dec 15, 2015 at 01:51:35PM -0600, Christoph Lameter wrote:
>> On Mon, 14 Dec 2015, Hal Rosenstock wrote:
>>
Mellanox should really confirm this for their hardware matrix.
>>>
>>> I am trying to get definitive answer to this.
>>
>> I was t
On Tue, Dec 15, 2015 at 01:51:35PM -0600, Christoph Lameter wrote:
> On Mon, 14 Dec 2015, Hal Rosenstock wrote:
>
> > > Mellanox should really confirm this for their hardware matrix.
> >
> > I am trying to get definitive answer to this.
>
> I was told today on a conf call with a couple of Mellano
On Mon, 14 Dec 2015, Hal Rosenstock wrote:
> > Mellanox should really confirm this for their hardware matrix.
>
> I am trying to get definitive answer to this.
I was told today on a conf call with a couple of Mellanox employees that
extended counters are always available.
--
To unsubscribe from
Hello all,
On Sat, Dec 12, 2015 at 5:26 AM, ira.weiny wrote:
> On Fri, Dec 11, 2015 at 12:25:35PM -0600, Christoph Lameter wrote:
>> Display the additional 64 bit counters available through the extended
>> set and replace the existing 32 bit counters if there is a 64 bit
>> alternative available.
On 12/11/2015 7:00 PM, Jason Gunthorpe wrote:
>> qib, mlx4 are fine. mlx5 should be as well I would think (I don't have that
>> hardware.)
I'm not 100% sure but I don't think that mthca supports the
PortCountersExtended attribute.
> I have no specifics to add, but I keep running into systems, ev
On Mon, 14 Dec 2015, Matan Barak wrote:
> > No idea what the counter is doing. Saw another EXT counter implementation
> > use 0 so I thought that was fine.
>
> It seems like a counter index, but I might be wrong though. If it is,
> don't we want to preserve the existing non-EXT schema for the new
On Mon, Dec 14, 2015 at 4:55 PM, Christoph Lameter wrote:
> On Mon, 14 Dec 2015, Matan Barak wrote:
>
>> > +static PORT_PMA_ATTR(unicast_rcv_packets , 0, 64, 384,
>> > IB_PMA_PORT_COUNTERS_EXT);
>> > +static PORT_PMA_ATTR(multicast_xmit_packets, 0, 64, 448,
>> > IB_PMA_PORT_C
On Mon, 14 Dec 2015, Matan Barak wrote:
> > +static PORT_PMA_ATTR(unicast_rcv_packets , 0, 64, 384,
> > IB_PMA_PORT_COUNTERS_EXT);
> > +static PORT_PMA_ATTR(multicast_xmit_packets, 0, 64, 448,
> > IB_PMA_PORT_COUNTERS_EXT);
> > +static PORT_PMA_ATTR(multicast_rcv_packets
On Fri, Dec 11, 2015 at 8:25 PM, Christoph Lameter wrote:
> Display the additional 64 bit counters available through the extended
> set and replace the existing 32 bit counters if there is a 64 bit
> alternative available.
>
> Note: This requires universal support of extended counters in
> the dev
On Fri, Dec 11, 2015 at 05:47:15PM -0700, Jason Gunthorpe wrote:
> On Fri, Dec 11, 2015 at 07:23:13PM -0500, ira.weiny wrote:
> > On Fri, Dec 11, 2015 at 05:00:47PM -0700, Jason Gunthorpe wrote:
> > >
> > > FWIW, I also hate the sysfs counters that reflect the PMA, these would
> > > be much better
On Fri, Dec 11, 2015 at 07:23:13PM -0500, ira.weiny wrote:
> On Fri, Dec 11, 2015 at 05:00:47PM -0700, Jason Gunthorpe wrote:
> >
> > FWIW, I also hate the sysfs counters that reflect the PMA, these would
> > be much better are free running, wrapping, non-resetting counters
> > unrelated to the PM
On Fri, Dec 11, 2015 at 05:00:47PM -0700, Jason Gunthorpe wrote:
>
> FWIW, I also hate the sysfs counters that reflect the PMA, these would
> be much better are free running, wrapping, non-resetting counters
> unrelated to the PMA. Something that doesn't zero after the SM samples
> it. Sounds like
> qib, mlx4 are fine. mlx5 should be as well I would think (I don't have that
> hardware.)
I have no specifics to add, but I keep running into systems, even
today, where the 64 bit counters don't work. The MAD might be there,
but several counters are wired to 0.
Not sure exactly which HW though.
On Fri, Dec 11, 2015 at 12:25:35PM -0600, Christoph Lameter wrote:
> Display the additional 64 bit counters available through the extended
> set and replace the existing 32 bit counters if there is a 64 bit
> alternative available.
>
> Note: This requires universal support of extended counters in
Display the additional 64 bit counters available through the extended
set and replace the existing 32 bit counters if there is a 64 bit
alternative available.
Note: This requires universal support of extended counters in
the devices. If there are still devices around that do not
support extended c
29 matches
Mail list logo
