[ovs-dev] [PATCH v6 1/2] Check and allocate free qdisc queue id for ports with qos parameters

[Babu Shanmugam]

On Monday 01 August 2016 09:14 PM, Ben Pfaff wrote:
> On Mon, Aug 01, 2016 at 07:03:14PM +0530, Babu Shanmugam wrote:
>>
>> On Thursday 28 July 2016 01:48 AM, Ben Pfaff wrote:
>>> On Wed, Jul 20, 2016 at 08:02:03PM +0530,bschanmu at redhat.com  wrote:
>>>>> ovn-northd processes the list of Port_Bindings and hashes the list of
>>>>> queues per chassis. When it finds a port with qos_parameters and without
>>>>> a queue_id, it allocates a free queue for the chassis that this port belongs.
>>>>> The queue_id information is stored in the options field of Port_binding table.
>>>>> Adds an action set_queue to the ingress table 0 of the logical flows
>>>>> which will be translated to openflow set_queue by ovn-controller
>>>>>
>>>>> ovn-controller opens the netdev corresponding to the tunnel interface's
>>>>> status:tunnel_egress_iface value and configures a HTB qdisc on it. Then for
>>>>> each SB port_binding that has queue_id set, it allocates a queue with the
>>>>> qos_parameters of that port. It also frees up unused queues.
>>>>>
>>>>> This patch replaces the older approach of policing
>>>>>
>>>>> Signed-off-by: Babu Shanmugam<bschanmu at redhat.com>
>>> I suggest folding in the following changes.  Notably, set_queue(0); was
>>> documented but didn't work because QDISC_MIN_QUEUE_ID was 1.
>>>
>>> This series has no tests.  I think that at least the DSCP marking
>>> feature could be tested with the existing OVN testing infrastructure.
>>> Will you work on that?
>> Ben,
>> I am trying to write a test case with the following sequence to test the
>> dscp marking.
>> - Add two ports (lp1, lp2) through ovn-nbctl and assign addresses
>> - Setup the vswitch db with external_ids:iface-id for the logical ports
>> created above
>> - Set options:qos_dscp on one logical port (lp1)  through ovn-nbctl
>> - ofproto/trace a simple ip packet originating from lp1, and check if the
>> final flow has the DSCP bit set or not
>>
>> ofproto/trace is tracing out correctly only when qos_dscp is not set. When
>> qos_dscp is set, the controller adds includes an additional action
>> "0x22->OXM_OF_IP_DSCP[]" in table 16. With this, ofproto/trace says it drops
>> the packet after it passes through table 0.
>>
>> Do you have any suggestion on how to overcome this?
> Hmm, that's odd.  What's the whole trace output look like?
It looks like the following

$ ovs-appctl ofproto/trace br-int 
'in_port=1,dl_src=f0:00:00:00:00:02,dl_dst=f0:00:00:00:00:01' -generate
Bridge: br-int
Flow: 
in_port=1,vlan_tci=0x0000,dl_src=f0:00:00:00:00:02,dl_dst=f0:00:00:00:00:01,dl_type=0x0000

Rule: table=0 cookie=0 priority=100,in_port=1
OpenFlow 
actions=set_field:0x1->reg13,set_field:0x1->metadata,set_field:0x1->reg14,resubmit(,16)

     Resubmitted flow: 
reg13=0x1,reg14=0x1,metadata=0x1,in_port=1,vlan_tci=0x0000,dl_src=f0:00:00:00:00:02,dl_dst=f0:00:00:00:00:01,dl_type=0x0000
     Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 
reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 
reg12=0x0 reg13=0x1 reg14=0x1 reg15=0x0
     Resubmitted  odp: drop
     Resubmitted megaflow: 
recirc_id=0,reg13=0,reg14=0,metadata=0,in_port=1,vlan_tci=0x0000/0x1000,dl_src=f0:00:00:00:00:02,dl_type=0x0000
     Rule: table=254 cookie=0 priority=0,reg0=0x2
     OpenFlow actions=drop

Final flow: 
reg13=0x1,reg14=0x1,metadata=0x1,in_port=1,vlan_tci=0x0000,dl_src=f0:00:00:00:00:02,dl_dst=f0:00:00:00:00:01,dl_type=0x0000
Megaflow: 
recirc_id=0,in_port=1,vlan_tci=0x0000/0x1000,dl_src=f0:00:00:00:00:02,dl_type=0x0000
Datapath actions: drop

--
Babu