<div>Caitlin,</div>
<div>can you clarify what you are suggesting?</div>
<div>Are you proposing that RDMA APIs for QoS setting is the not the way to go?</div>
<div>Are you proposing to use netdev mechanisms for setting RFC2474 DS fields to</div>
<div>be used for RDMA QoS setting?</div>
<div>Something else?</div>
<div>Thanks,</div>
<div>Arkady <br><br></div>
<div class="gmail_quote">On Fri, Apr 3, 2009 at 12:13 PM, Caitlin Bestler <span dir="ltr"><<a href="mailto:caitlin.bestler@gmail.com">caitlin.bestler@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>
<div></div>
<div class="h5">On Thu, Apr 2, 2009 at 5:28 PM, Sean Hefty <<a href="mailto:sean.hefty@intel.com">sean.hefty@intel.com</a>> wrote:<br>>>So the plan is to hook up service_type/tos to VLAN and skb->priority<br>
>>for iWARP? But since we do not setup socket connection explicitly<br>>>we can not use SO_PRIORITY field to do it. Is this correct?<br>>>Do we have a plan on how to hook up tos without socket?<br>><br>
> I really don't have any plans at this time to link QoS and iWarp.  Someone<br>> working closer with iWarp would need to provide any sort of implementation.<br>><br></div></div>Implementing a parallel solution for VLAN/priority and other policy controls<br>
for iWARP connections would be terribly wasteful, both in development time<br>and in the need for network administrators to use two different sets of tools<br>to implement what should be an integrated set of policies.<br>
<br>But that would require the netdev stack to acknowledge the existence of<br>offloaded connections, and instead of just waiting for them to go away insist<br>that they follow a minimal set of rules to provide co-ordinated management.<br>
<br>In my opinion this won't happen because vendors push for it. Fabric users<br>are going to have to make their need for uniform control of VLAN/priorities/etc.<br>understood.<br></blockquote></div><br><br clear="all">
<br>-- <br>Cheers,<br>Arkady Kanevsky<br>