Roland Dreier <[EMAIL PROTECTED]> wrote on 17.07.2007 19:52:55:
> At a higher level, I'm left wondering why nobody talked about multiple
> EQs during the last months of the 2.6.22 process and now all of a
> sudden it becomes urgent in the last few days of the 2.6.23 merge
> window. That's not
Roland Dreier [EMAIL PROTECTED] wrote on 17.07.2007 19:52:55:
At a higher level, I'm left wondering why nobody talked about multiple
EQs during the last months of the 2.6.22 process and now all of a
sudden it becomes urgent in the last few days of the 2.6.23 merge
window. That's not really
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
>
> > Here's some anecdotal evidence :)
> > http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
>
> Right, but then we wen
> Here's some anecdotal evidence :)
> http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
Right, but then we went on to say that we probably want to use
multiple vectors to separate out multiple HCA ports rather than
send/sreceive on the same port. And the current IPoIB
Here's some anecdotal evidence :)
http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
Right, but then we went on to say that we probably want to use
multiple vectors to separate out multiple HCA ports rather than
send/sreceive on the same port. And the current IPoIB
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
Here's some anecdotal evidence :)
http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
Right, but then we went on to say that we probably want to use
multiple
> I still haven't seen much code using the feature or
> even any anecdotal information about the performance impact.
Here's some anecdotal evidence :)
http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
--
MST
-
To unsubscribe from this list: send the line "unsubscribe
> No, I've no figures to provide here. The background of this dist_eqs
> option is actually to allow us testing across all event queues
> without to change the testcases resp consumers to use certain
> event queue number. Thus, I should comment it as EXPERIMENTAL?
Seems like it's just
Roland Dreier <[EMAIL PROTECTED]> wrote on 16.07.2007 18:04:26:
> Do you have any data on how well this round-robin assignment works?
> It seems not quite right to me for the driver to advertise nr_eqs
> completion vectors, but then if round-robin is turned on to ignore the
> consumer's decision
Roland Dreier <[EMAIL PROTECTED]> wrote on 16.07.2007 18:04:26:
> It seems not quite right to me for the driver to advertise nr_eqs
> completion vectors, but then if round-robin is turned on to ignore the
> consumer's decision about which vector to use.
The round-robin feature was primarily
> The eHCA driver can now handle multiple event queues (read: interrupt
> sources) instead of one. The number of available EQs is selected via the
> nr_eqs module parameter.
> CQs are either assigned to the EQs based on the comp_vector index or, if the
> dist_eqs module parameter is
The eHCA driver can now handle multiple event queues (read: interrupt
sources) instead of one. The number of available EQs is selected via the
nr_eqs module parameter.
CQs are either assigned to the EQs based on the comp_vector index or, if the
dist_eqs module parameter is supplied,
Roland Dreier [EMAIL PROTECTED] wrote on 16.07.2007 18:04:26:
It seems not quite right to me for the driver to advertise nr_eqs
completion vectors, but then if round-robin is turned on to ignore the
consumer's decision about which vector to use.
The round-robin feature was primarily meant as
Roland Dreier [EMAIL PROTECTED] wrote on 16.07.2007 18:04:26:
Do you have any data on how well this round-robin assignment works?
It seems not quite right to me for the driver to advertise nr_eqs
completion vectors, but then if round-robin is turned on to ignore the
consumer's decision about
No, I've no figures to provide here. The background of this dist_eqs
option is actually to allow us testing across all event queues
without to change the testcases resp consumers to use certain
event queue number. Thus, I should comment it as EXPERIMENTAL?
Seems like it's just
I still haven't seen much code using the feature or
even any anecdotal information about the performance impact.
Here's some anecdotal evidence :)
http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
--
MST
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
From: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
The eHCA driver can now handle multiple event queues (read: interrupt
sources) instead of one. The number of available EQs is selected via the
nr_eqs module parameter.
CQs are either assigned to the EQs based on the comp_vector index or, if the
dist_eqs
From: Hoang-Nam Nguyen [EMAIL PROTECTED]
The eHCA driver can now handle multiple event queues (read: interrupt
sources) instead of one. The number of available EQs is selected via the
nr_eqs module parameter.
CQs are either assigned to the EQs based on the comp_vector index or, if the
dist_eqs
18 matches
Mail list logo
