On Monday 01 August 2016 10:09 PM, Babu Shanmugam wrote:
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,bscha...@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<bscha...@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
Turns out that it was due to a bug in the DSCP marking code. The DSCP
marking was done at L2 stage without any additional flows to handle the
L2 packets itself. So any L3 packet gets dropped at this stage.
I moved the DSCP marking logic to L3 pipeline with additional tests and
submitted the patches for review.
Sorry for the trouble,
Babu
--
Babu
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev