Hey Hal, On Thu, 2008-10-09 at 08:37 -0400, Hal Rosenstock wrote: > Hi again Al, > > On Wed, Oct 8, 2008 at 6:45 PM, Al Chu <[EMAIL PROTECTED]> wrote: > > Hey Hal, > > > > On Wed, 2008-10-08 at 09:44 -0400, Hal Rosenstock wrote: > >> Hi Al, > >> > >> On Wed, Oct 8, 2008 at 6:26 AM, Al Chu <[EMAIL PROTECTED]> wrote: > >> > Hey Hal, > >> > > >> > On Wed, 2008-10-08 at 07:03 -0400, Hal Rosenstock wrote: > >> >> Al, > >> >> > >> >> On Tue, Oct 7, 2008 at 6:54 PM, Al Chu <[EMAIL PROTECTED]> wrote: > >> >> > Hey Sasha, > >> >> > > >> >> > We have a switch here that does not report the AllPortSelect flag as a > >> >> > capability. It's pretty annoying typing each port on the switch or > >> >> > always having to script around this one oddball switch we have. So I > >> >> > added an option --loop_ports for perfquery. If you want to do > >> >> > something > >> >> > to all the ports on the CA/Switch, but AllPortSelect isn't available, > >> >> > it > >> >> > loops through all the available ports instead. > >> >> > >> >> Why not add simulated AllPortSelect for multiple ports rather than add > >> >> another perquery option for this ? > >> > > >> > I did try that, and it did seem to work for the switches we had. But > >> > when I read the IB spec, it said something to the affect that if a > >> > system doesn't support AllPortSelect, setting the PortSelect field to > >> > 0xFF was undefined behavior. > >> > >> I was suggesting that the emulation support (when AllPortSelect is not > >> supported) be enhanced for multiple ports and work on both CAs and all > >> switches. The one difference is one response for AllPortSelect > >> (whether emulated or not) v. many responses for port loop. > > > > Oh. I thought you were referring the the workaround "simulation" that > > was in the original code. But you're referring to aggregating the > > data/output make it look like AllPortSelect was supported. I'll put > > this on the TODO. > > So it seems that the reason for adding an additional option for this > is that the lack of this support ? Are there any other uses ?
I made the --loop_ports option b/c I just didn't want to change the default behavior perfquery. But we could easily make it an automatic if the AllPortsSelect flag isn't supported. Thinking about it, there is a bit of a subtlety in the command line options and expectations. If a user inputs a port of '255', to me this means that the user wants to do an AllPortSelect and we should error out if AllPortSelect isn't supported. If a user inputs the '-a' option, it suggests that they want perfquery to operate on every port, suggesting that we could automatically loop if they don't input --loop_ports. Al > -- Hal > > >> > >> >> > There was already a workaround in the tool for a CA that did not > >> >> > support > >> >> > the AllPortSelect flag. I get the feeling the workaround may have > >> >> > been > >> >> > for a specific hardware, so I kept the workaround in there. > >> >> > >> >> > Al > >> >> > > >> >> > -- > >> >> > Albert Chu > >> >> > [EMAIL PROTECTED] > >> >> > Computer Scientist > >> >> > High Performance Systems Division > >> >> > Lawrence Livermore National Laboratory > >> >> > > >> >> > _______________________________________________ > >> >> > general mailing list > >> >> > [email protected] > >> >> > http:// lists.openfabrics.org/cgi-bin/mailman/listinfo/general > >> >> > > >> >> > To unsubscribe, please visit http:// > >> >> > openib.org/mailman/listinfo/openib-general > >> >> > > >> >> > >> >> There are also 2 for loops which are not correct for some switches: > >> >> for (i = 1; i <= num_ports; i++) > >> > > >> > I guess I've never seen a switch that doesn't go from 1 to num_ports. > >> > Is there something else I need to handle? > >> > >> Yes, per the spec, enhanced SP0 supports PortCounters. All your > >> switches likely support AllPortSelect so it's not an issue there. > > > > Ok I see now. Wasn't aware of it. I'll get a patch together. > > > > Thanks, > > Al > > > >> -- Hal > >> > >> > Al > >> > > >> >> -- Hal > >> >> > >> > -- > >> > Albert Chu > >> > [EMAIL PROTECTED] > >> > Computer Scientist > >> > High Performance Systems Division > >> > Lawrence Livermore National Laboratory > >> > > >> > > >> > > -- > > Albert Chu > > [EMAIL PROTECTED] > > Computer Scientist > > High Performance Systems Division > > Lawrence Livermore National Laboratory > > > > > -- Albert Chu [EMAIL PROTECTED] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
