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.