On Feb 2, 7:25 pm, "Rustad, Mark D" <[email protected]> wrote: > Shyam, > > On Wednesday, February 02, 2011 4:00 PM, shyam iyer wrote: > > > On Feb 1, 6:10 pm, Mark Rustad <[email protected]> wrote: > > <SNIP> > > > > > > +static void set_dcb_priority(struct iscsi_conn *conn, const char > > > *devname) > > > +{ > > > + int pri_mask = 0; > > > + > > > + pri_mask = get_dcb_app_pri_by_port(devname, ISCSI_DEFAULT_PORT); > > > + if (pri_mask < 0) > > > + log_debug(2, "Getting priority for %s returned %d", > > > + devname, pri_mask); > > > + else if (pri_mask == 0) > > > + log_debug(2, "No priority for %s", devname); > > > + else { > > > + int pri = select_priority(conn, pri_mask); > > > + > > > + log_debug(1, "Setting socket priority to %d", pri); > > > + setsockopt(conn->socket_fd, SOL_SOCKET, > > > + SO_PRIORITY, &pri, sizeof(pri)); > > > Are we assuming 0-6 only as the priority ? > > No, it could be 0-7. > > > I thought it should be 0-7 and so requiring CAP_NET_ADMIN > > Hmmm. I think I always see it running as root. So what needs to be done > to handle other security models? > > > Which brings me to the related question. > > > How will the priority be handled when you have multipathed iSCSI > > sessions through the same net device. > > > Scenario - > > 1st Session priority set to 3 > > Change priority to 4 > > Connect 2nd session. I am assuming the priority for the new connection > > socket is 4. > > Yes. A deficiency in the current implementation is that the first session > will stay at 3, but the second one would be at 4. >
And to change the priority in the kernel via userspace are you posting a related patch to dcbtool ? Specifically adding the iSCSI subtype.. > > Are these two sessions going to be through different H/W queues if the > > session is through the same ethX > > Yes, they would be. > > > So would it be correct to say that the mapping of the SO_PRIORITY is > > to the tc configured HW queue? > > John Fastabend could answer this more specifically, but I do see the packets > going > to different hardware queues when different priorities are used. Right now I > am not seeing the priority indicated in the VLAN header of transmitted > packets and I think that is a bug. Note that I have been testing with kernels > that include changes that may not be upstream yet. I guess I should check on > where those changes are, but I have other things to do first. > > -- > Mark Rustad, LAN Access Division, Intel Corporation. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
