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

Ben Pfaff blp at ovn.org
Mon Jul 4 05:23:53 UTC 2016


On Mon, Jul 04, 2016 at 10:49:50AM +0530, Babu Shanmugam wrote:
> 
> 
> On Saturday 25 June 2016 01:40 AM, Ben Pfaff wrote:
> >On Fri, Jun 24, 2016 at 02:59:15PM +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>
> >Thanks for the new version.
> >
> >I'm passing along an incremental to fold in.  Some of the changes are
> >style.  Others:
> >
> >    * Put hmap_node at the start of structs because it makes valgrind's
> >      memory leak checker confident about pointers instead of calling
> >      them "possible leaks".
> >
> >    * Avoid trying to modify the OVS database when there's no transaction
> >      open.
> >
> >    * Log errors from netdev operations.
> >
> >    * Don't log a warning when setting up QoS.
> >
> >    * Fix a couple of memory leaks.
> >
> >I was going to just apply this but there's an ongoing situation where we
> >might need to revert patches in this same area (see
> >http://openvswitch.org/pipermail/dev/2016-June/073608.html) and I don't
> >want to make that harder.  So please sit on this until that situation
> >resolves.
> Hi Ben,
> Should I rebase this patch publish it again?

Yes, please.

Thanks,

Ben.



More information about the dev mailing list