Hello Aravind, You still need to use an output action in step 3. The output action selects the port to use, and the queue id selects the queue on the given output port.
BR, Zoltan >-----Original Message----- >From: openflow-discuss [mailto:openflow-discuss- >boun...@lists.stanford.edu] On Behalf Of Aravindhan Dhanasekaran >Sent: Saturday, October 11, 2014 6:50 AM >To: openflow-discuss@lists.stanford.edu >Subject: [openflow-discuss] Using queues in OpenFlow soft switch 13 > >[I believe this to be more of a ofsoftswitch specific question, but I'm >posting it >here as ofsoftswitch folks follow this list. Apologies for the wide >distribution.] > >Hello, > >I'm trying to use queues in ofsoftswitch13 for a small traffic shaping/limiting >experiment as discussed at http://archive.openflow.org/wk/index.php/Slicing > >I'm using top-of-trunk versions of Mininet and ofsoftswitch13 in my testbed >and have two streams of TCP and UDP traffic. > >My topology: >h1 [eth1] <-----> [s1-eth1] s1 [s1-eth2] <-----> [eth1] h2 > >My flow tables: >$ sudo dpctl unix:/tmp/s1 stats-flow > {table="0", match="oxm{eth_type="0x800", ip_proto="6"}", >dur_s="3740", dur_ns="249000", prio="32768", idle_to="0", hard_to="0", >cookie="0x0", pkt_cnt="4000521", byte_cnt="4093372606", >insts=[meta{meta="0x6", mask="0xffffffffffffffff"}, goto{table="3"}]}, > > {table="0", match="oxm{eth_type="0x800", ip_proto="17"}", >dur_s="2622", dur_ns="608000", prio="32768", idle_to="0", hard_to="0", >cookie="0x0", pkt_cnt="65574", byte_cnt="99147888", >insts=[meta{meta="0x11", mask="0xffffffffffffffff"}, goto{table="4"}]}, > {table="3", match="oxm{in_port="1", metadata="0x6"}", >dur_s="3728", dur_ns="131000", prio="32768", idle_to="0", hard_to="0", >cookie="0x0", pkt_cnt="1355622", byte_cnt="90368912", >insts=[apply{acts=[out{port="2"}]}]}, > {table="3", match="oxm{in_port="2", metadata="0x6"}", >dur_s="3728", dur_ns="114000", prio="32768", idle_to="0", hard_to="0", >cookie="0x0", pkt_cnt="2644899", byte_cnt="4003003694", >insts=[apply{acts=[out{port="1"}]}]}, > {table="4", match="oxm{in_port="1", metadata="0x17"}", >dur_s="2670", dur_ns="800000", prio="32768", idle_to="0", hard_to="0", >cookie="0x0", pkt_cnt="3", byte_cnt="4536", >insts=[apply{acts=[out{port="2"}]}]}, > {table="4", match="oxm{in_port="2", metadata="0x17"}", >dur_s="1951", dur_ns="392000", prio="32768", idle_to="0", hard_to="0", >cookie="0x0", pkt_cnt="1968", byte_cnt="2975616", >insts=[apply{acts=[out{port="1"}]}]}]} > > >Test setup: > 1. Initially, I've both TCP and UDP traffic, originating at h2 and > destined to h1, >to use the same egress interface (s1-eth1) whose bandwidth has been limited >to 10kbps. UDP takes over all the bandwidth as expected. > 2. I then created two queues on the egress interface with min guaranteed >rate as 7 and 3 kbps to be used for TCP and UDP respectively. > >$ sudo dpctl unix:/tmp/s1 queue-mod 1 1 7 $ sudo dpctl unix:/tmp/s1 queue- >mod 1 1 3 $ sudo dpctl unix:/tmp/s1 stats-queue SENDING (xid=0xF0FF00F0): >stat_req{type="queue", flags="0x0", port="any", q="all"} > >RECEIVED (xid=0xF0FF00F0): >stat_repl{type="queue", flags="0x0", stats=[{port="1", q="1", tx_bytes="0", >tx_pkt="0", tx_err="0"}, {port="1", q="2", tx_bytes="0", tx_pkt="0", >tx_err="0"}]} > > 3. I modified my flows to use the queue instead of directly sending it out > of >the port. After tj $ sudo dpctl unix:/tmp/s1 flow-mod cmd=add,table=3 >meta=0x6,in_port=2 apply:queue1 $ sudo dpctl unix:/tmp/s1 flow-mod >cmd=add,table=4 meta=0x11,in_port=2 apply:queue2 $ sudo dpctl >unix:/tmp/s1 stats-flow | grep "q=" > {table="3", match="oxm{in_port="2", metadata="0x6"}", dur_s="31", >dur_ns="516000", prio="32768", idle_to="0", hard_to="0", cookie="0x0", >pkt_cnt="62", byte_cnt="93868", insts=[apply{acts=[queue{q="1"}]}]}, > {table="4", match="oxm{in_port="2", metadata="0x17"}", >dur_s="21", dur_ns="535000", prio="32768", idle_to="0", hard_to="0", >cookie="0x0", pkt_cnt="0", byte_cnt="0", >insts=[apply{acts=[queue{q="2"}]}]}]} > > 4. After step 3, my traffic (both TCP and UDP) seems to be dropped at s1- >eth1. I verified this using tcpdump on the ingress interface (s1-eth2) and I >could see my traffic there. > >Can anyone please explain me what's wrong with my setup? > >Also, how would the switch know which queue of which port should be used >for egress if we just specify the queue ID alone as done in step 3? Or should >queue IDs be globally (across all datapath ports) unique? > >Thanks, >/Aravind >_______________________________________________ >openflow-discuss mailing list >openflow-discuss@lists.stanford.edu >https://mailman.stanford.edu/mailman/listinfo/openflow-discuss _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
