On Tuesday, January 21, 2020 at 1:15:29 AM UTC-8, Bobby wrote:
>
> Hi all,
>
> I have a question please. Are these todo's finally part of Open-iSCSi
> initiator?
>
> Thanks
>
No, not really. It's a "hard problem", and offload cards have somewhat
worked around the problem by doing all of the wo
Hi all,
I have a question please. Are these todo's finally part of Open-iSCSi
initiator?
Thanks
On Wednesday, January 7, 2015 at 5:57:14 PM UTC+1, hare wrote:
>
> On 01/07/2015 05:25 PM, Sagi Grimberg wrote:
> > Hi everyone,
> >
> > Now that scsi-mq is fully included, we need an iSCSI initia
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 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 01/11/15 10:40, Sagi Grimberg wrote:
> I would say there is no need for specific coordination from iSCSI PoV.
> This is exactly what flow steering is designed for. As I see it, in
> order to get the TX/RX to match rings, the user can attach 5-tuple rules
> (using standard ethtool) to steer packe
On 1/12/2015 10:05 PM, Mike Christie wrote:
On 01/11/2015 03:23 AM, Sagi Grimberg wrote:
On 1/9/2015 8:00 PM, Michael Christie wrote:
Session wide command sequence number synchronization isn't something to
be removed as part of the MQ work. It's a iSCSI/iSER protocol
requirement.
That is,
On 1/12/2015 2:56 PM, Bart Van Assche wrote:
On 01/11/15 10:40, Sagi Grimberg wrote:
I would say there is no need for specific coordination from iSCSI PoV.
This is exactly what flow steering is designed for. As I see it, in
order to get the TX/RX to match rings, the user can attach 5-tuple rules
On 01/11/2015 03:40 AM, Sagi Grimberg wrote:
> On 1/9/2015 10:19 PM, Mike Christie wrote:
>> On 01/09/2015 12:28 PM, Hannes Reinecke wrote:
>>> On 01/09/2015 07:00 PM, Michael Christie wrote:
On Jan 8, 2015, at 11:03 PM, Nicholas A. Bellinger
wrote:
> On Thu, 2015-01-08 at
On 01/11/2015 03:23 AM, Sagi Grimberg wrote:
> On 1/9/2015 8:00 PM, Michael Christie wrote:
>
>>>
>>> Session wide command sequence number synchronization isn't something to
>>> be removed as part of the MQ work. It's a iSCSI/iSER protocol
>>> requirement.
>>>
>>> That is, the expected + max
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 1/9/2015 10:19 PM, Mike Christie wrote:
On 01/09/2015 12:28 PM, Hannes Reinecke wrote:
On 01/09/2015 07:00 PM, Michael Christie wrote:
On Jan 8, 2015, at 11:03 PM, Nicholas A. Bellinger wrote:
On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote:
On Thu, 2015-01-08 at 14:57 -0800, N
On 1/9/2015 8:00 PM, Michael Christie wrote:
Session wide command sequence number synchronization isn't something to
be removed as part of the MQ work. It's a iSCSI/iSER protocol
requirement.
That is, the expected + maximum sequence numbers are returned as part of
every response PDU, which
On 01/09/2015 12:28 PM, Hannes Reinecke wrote:
> On 01/09/2015 07:00 PM, Michael Christie wrote:
>>
>> On Jan 8, 2015, at 11:03 PM, Nicholas A. Bellinger
>> wrote:
>>
>>> On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote:
On Thu, 2015-01-08 at 14:57 -0800, Nicholas A. Bellinger wrote:
On Fri, 2015-01-09 at 19:28 +0100, Hannes Reinecke wrote:
[...]
> > I think you are assuming we are leaving the iscsi code as it is today.
> >
> > For the non-MCS mq session per CPU design, we would be allocating and
> > binding the session and its resources to specific CPUs. They would only
> > b
On 01/09/2015 07:00 PM, Michael Christie wrote:
>
> On Jan 8, 2015, at 11:03 PM, Nicholas A. Bellinger
> wrote:
>
>> On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote:
>>> On Thu, 2015-01-08 at 14:57 -0800, Nicholas A. Bellinger wrote:
On Thu, 2015-01-08 at 14:29 -0800, James Bottom
On Jan 8, 2015, at 11:03 PM, Nicholas A. Bellinger wrote:
> On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote:
>> On Thu, 2015-01-08 at 14:57 -0800, 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
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 Thu, 2015-01-08 at 21:03 -0800, Nicholas A. Bellinger wrote:
> On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote:
> > On Thu, 2015-01-08 at 14:57 -0800, 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,
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 Wed 07-01-15 09:22:13, Lee Duncan wrote:
> 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 trans
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 maintainer I'd like to discuss the way we would choose
to imple
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 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.
--
You r
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 Thu, 2015-01-08 at 14:57 -0800, 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 wr
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 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 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 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
36 matches
Mail list logo
