On Tue, Mar 29 2011 at 4:12pm -0400, Shyam_Iyer@xxxxxxxx <Shyam_Iyer@xxxxxxxx> wrote: > > > > -----Original Message----- > > From: Mike Snitzer [mailto:snitzer@xxxxxxxxxx] > > Sent: Tuesday, March 29, 2011 4:00 PM > > To: Iyer, Shyam > > Cc: vgoyal@xxxxxxxxxx; lsf@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux- > > scsi@xxxxxxxxxxxxxxx; linux-fsdevel@xxxxxxxxxxxxxxx; > > rwheeler@xxxxxxxxxx; device-mapper development > > Subject: Re: Preliminary Agenda and Activities for LSF > > > > On Tue, Mar 29 2011 at 3:13pm -0400, > > Shyam_Iyer@xxxxxxxx <Shyam_Iyer@xxxxxxxx> wrote: > > > > > > > > Above is pretty generic. Do you have specific > > needs/ideas/concerns? > > > > > > > > > > > > Thanks > > > > > > Vivek > > > > > Yes.. if I limited by Ethernet b/w to 40% I don't need to limit > > I/O > > > > b/w via cgroups. Such bandwidth manipulations are network switch > > driven > > > > and cgroups never take care of these events from the Ethernet > > driver. > > > > > > > > So if IO is going over network and actual bandwidth control is > > taking > > > > place by throttling ethernet traffic then one does not have to > > specify > > > > 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. > > > > > > - 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 > > > > > > 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. > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
