Re: Preliminary Agenda and Activities for LSF

On Tue, Mar 29 2011 at  4:12pm -0400,
Shyam_Iyer@dell.com [off-list ref] wrote:

quoted

-----Original Message-----
From: Mike Snitzer [mailto:snitzer@redhat.com]
Sent: Tuesday, March 29, 2011 4:00 PM
To: Iyer, Shyam
Cc: vgoyal@redhat.com; lsf@lists.linux-foundation.org; linux-
scsi@vger.kernel.org; linux-fsdevel@vger.kernel.org;
rwheeler@redhat.com; device-mapper development
Subject: Re: Preliminary Agenda and Activities for LSF

On Tue, Mar 29 2011 at  3:13pm -0400,
Shyam_Iyer@dell.com [off-list ref] wrote:

quoted

quoted

quoted

quoted

Above is pretty generic. Do you have specific

needs/ideas/concerns?

quoted

quoted

quoted

quoted

Thanks
Vivek

Yes.. if I limited by Ethernet b/w to 40% I don't need to limit

I/O

quoted

quoted

b/w via cgroups. Such bandwidth manipulations are network switch

driven

quoted

quoted

and cgroups never take care of these events from the Ethernet

driver.

quoted

quoted

So if IO is going over network and actual bandwidth control is

taking

quoted

quoted

place by throttling ethernet traffic then one does not have to

specify

quoted

quoted

block cgroup throttling policy and hence no need for cgroups to be
worried
about ethernet driver events?

I think I am missing something here.

Vivek

Well.. here is the catch.. example scenario..

- Two iSCSI I/O sessions emanating from Ethernet ports eth0, eth1

multipathed together. Let us say round-robin policy.

quoted

- The cgroup profile is to limit I/O bandwidth to 40% of the

multipathed I/O bandwidth. But the switch may have limited the I/O
bandwidth to 40% for the corresponding vlan associated with one of the
eth interface say eth1

quoted

The computation that the bandwidth configured is 40% of the available

bandwidth is false in this case.  What we need to do is possibly push
more I/O through eth0 as it is allowed to run at 100% of bandwidth by
the switch.

quoted

Now this is a dynamic decision and multipathing layer should take

care of it.. but it would need a hint..

No hint should be needed.  Just use one of the newer multipath path
selectors that are dynamic by design: "queue-length" or "service-time".

This scenario is exactly what those path selectors are meant to
address.

Mike

Since iSCSI multipaths are essentially sessions one could configure
more than one session through the same ethX interface. The sessions
need not be going to the same LUN and hence not governed by the same
multipath selector but the bandwidth policy group would be for a group
of resources.

Then the sessions don't correspond to the same backend LUN (and by
definition aren't part of the same mpath device).  You're really all
over the map with your talking points.

I'm having a hard time following you.

Mike