Sagi Grimberg wrote on 01/08/2015 05:45 AM:
>> RFC 3720 namely requires that iSCSI numbering is
>> session-wide. This means maintaining a single counter for all MC/S
>> sessions. Such a counter would be a contention point. I'm afraid that
>> because of that counter performance on a multi-socket ini
On 1
9/2015 3:31 PM, Bart Van Assche wrote:
On 01/09/15 12:39, Sagi Grimberg wrote:
On 1/8/2015 4:11 PM, Bart Van Assche wrote:
On 01/08/15 14:45, Sagi Grimberg wrote:
Actually I started with that approach, but the independent connections
under a single session (I-T-Nexus) violates the command
On 01/09/15 12:39, Sagi Grimberg wrote:
> On 1/8/2015 4:11 PM, Bart Van Assche wrote:
>> On 01/08/15 14:45, Sagi Grimberg wrote:
>>> Actually I started with that approach, but the independent connections
>>> under a single session (I-T-Nexus) violates the command ordering
>>> requirement. Plus, suc
On 1/8/2015 4:11 PM, Bart Van Assche wrote:
On 01/08/15 14:45, Sagi Grimberg wrote:
Actually I started with that approach, but the independent connections
under a single session (I-T-Nexus) violates the command ordering
requirement. Plus, such a solution is specific to iSER...
Hello Sagi,
Whi
On 1/9/2015 1:26 AM, Mike Christie wrote:
I am not sure if we want this to be a deciding factor. I think the
session wide lock is something that can be removed in the main IO paths.
A lot of what it is used for now is cmd/task related handling like list
accesses. When we have the scsi layer all
On 1/7/15, 3:39 PM, Mike Christie wrote:
So pretty non controversial I hope
Ok, maybe a little controversial. Let me work with Sagi on his MCS (tcp
connection per CPU approach) patch and update my session per CPU patch
and we can do some benchmarking and tracing and see what is up.
--
To uns
On 1/8/15, 4:57 PM, Nicholas A. Bellinger wrote:
On Thu, 2015-01-08 at 14:29 -0800, James Bottomley wrote:
On Thu, 2015-01-08 at 14:16 -0800, Nicholas A. Bellinger wrote:
On Thu, 2015-01-08 at 08:50 +0100, Bart Van Assche wrote:
On 01/07/15 22:39, Mike Christie wrote:
On 01/07/2015 10:57 AM,
On 1/8/15, 1:50 AM, Bart Van Assche wrote:
On 01/07/15 22:39, Mike Christie wrote:
On 01/07/2015 10:57 AM, Hannes Reinecke wrote:
On 01/07/2015 05:25 PM, Sagi Grimberg wrote:
Hi everyone,
Now that scsi-mq is fully included, we need an iSCSI initiator that
would use it to achieve scalable perf
On Thu, 2015-01-08 at 14:29 -0800, James Bottomley wrote:
> On Thu, 2015-01-08 at 14:16 -0800, Nicholas A. Bellinger wrote:
> > On Thu, 2015-01-08 at 08:50 +0100, Bart Van Assche wrote:
> > > On 01/07/15 22:39, Mike Christie wrote:
> > > > On 01/07/2015 10:57 AM, Hannes Reinecke wrote:
> > > >> On
On Thu, 2015-01-08 at 14:16 -0800, Nicholas A. Bellinger wrote:
> On Thu, 2015-01-08 at 08:50 +0100, Bart Van Assche wrote:
> > On 01/07/15 22:39, Mike Christie wrote:
> > > On 01/07/2015 10:57 AM, Hannes Reinecke wrote:
> > >> On 01/07/2015 05:25 PM, Sagi Grimberg wrote:
> > >>> Hi everyone,
> > >
On Thu, 2015-01-08 at 08:50 +0100, Bart Van Assche wrote:
> On 01/07/15 22:39, Mike Christie wrote:
> > On 01/07/2015 10:57 AM, Hannes Reinecke wrote:
> >> On 01/07/2015 05:25 PM, Sagi Grimberg wrote:
> >>> Hi everyone,
> >>>
> >>> Now that scsi-mq is fully included, we need an iSCSI initiator that
On 1/8/2015 4:50 PM, James Bottomley wrote:
If people want to add something like round robin connection selection in
the iscsi layer, then I think we want to leave that for after the
initial merge, so people can argue about that separately.
Well, you're right, we can argue about it later, but
> On Jan 8, 2015, at 9:11 AM, Bart Van Assche wrote:
>
> On 01/08/15 14:45, Sagi Grimberg wrote:
>> Actually I started with that approach, but the independent connections
>> under a single session (I-T-Nexus) violates the command ordering
>> requirement. Plus, such a solution is specific to iSER
On Wed, 2015-01-07 at 15:39 -0600, Mike Christie wrote:
> On 01/07/2015 10:57 AM, Hannes Reinecke wrote:
> > On 01/07/2015 05:25 PM, Sagi Grimberg wrote:
> >> Hi everyone,
> >>
> >> Now that scsi-mq is fully included, we need an iSCSI initiator that
> >> would use it to achieve scalable performance
On 01/08/15 14:45, Sagi Grimberg wrote:
Actually I started with that approach, but the independent connections
under a single session (I-T-Nexus) violates the command ordering
requirement. Plus, such a solution is specific to iSER...
Hello Sagi,
Which command ordering requirement are you refer
On 1/8/2015 9:50 AM, Bart Van Assche wrote:
On 01/07/15 22:39, Mike Christie wrote:
On 01/07/2015 10:57 AM, Hannes Reinecke wrote:
On 01/07/2015 05:25 PM, Sagi Grimberg wrote:
Hi everyone,
Now that scsi-mq is fully included, we need an iSCSI initiator that
would use it to achieve scalable per
On 01/07/15 22:39, Mike Christie wrote:
On 01/07/2015 10:57 AM, Hannes Reinecke wrote:
On 01/07/2015 05:25 PM, Sagi Grimberg wrote:
Hi everyone,
Now that scsi-mq is fully included, we need an iSCSI initiator that
would use it to achieve scalable performance. The need is even greater
for iSCSI
On 01/07/2015 10:57 AM, Hannes Reinecke wrote:
> On 01/07/2015 05:25 PM, Sagi Grimberg wrote:
>> Hi everyone,
>>
>> Now that scsi-mq is fully included, we need an iSCSI initiator that
>> would use it to achieve scalable performance. The need is even greater
>> for iSCSI offload devices and transpor
On 01/07/2015 08:25 AM, Sagi Grimberg wrote:
> Hi everyone,
>
> Now that scsi-mq is fully included, we need an iSCSI initiator that
> would use it to achieve scalable performance. The need is even greater
> for iSCSI offload devices and transports that support multiple HW
> queues. As iSER maintai
On Wed, 2015-01-07 at 18:25 +0200, Sagi Grimberg wrote:
> Hi everyone,
>
> Now that scsi-mq is fully included, we need an iSCSI initiator that
> would use it to achieve scalable performance. The need is even greater
> for iSCSI offload devices and transports that support multiple HW
> queues. As i
On 01/07/2015 05:25 PM, Sagi Grimberg wrote:
> Hi everyone,
>
> Now that scsi-mq is fully included, we need an iSCSI initiator that
> would use it to achieve scalable performance. The need is even greater
> for iSCSI offload devices and transports that support multiple HW
> queues. As iSER maintai
21 matches
Mail list logo
