On 2/2/2011 4:25 PM, Rustad, Mark D 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. > >> 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. >
Hi Shyam, The mapping depends on the priority to TC mapping configured in the net device. This can be configured through the mqprio qdisc or with the base driver dflts which is 1:1 for ixgbe and 8 traffic classes. Note the mqprio qdisc is in net-next-2.6 tree and should get merged into Linus' tree during the next kernel merge window. Also there will need to be some enabling of iproute2 that I haven't done yet. For now the defaults are used. John. -- 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.
