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.

-- 
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.

Reply via email to