orchagent/portsorch: Keeping sched_group_ids in port

[arvbb]

What I did
Based on comments from PR #2174, keeping scheduler groups in port and reusing them in qosorch.

Why I did it
Avoiding querying twice for scheduler groups.

How I verified it
sudo config warm_restart enable swss
sudo service swss restart
and
warm-boot

[stephenxs]

As comments.
Also suggest adding a mock test to simulate port removal and make sure no error.

[stephenxs]

This avoids the memory issue but there is still a memory leak issue in DPB. eg. if the old port is removed then a set of new ports are created, the SAI OID of ports will be changed but m_scheduler_group_port_info[<SAI OID of old port>] won't be removed. Eventually, m_scheduler_group_port_info will contain a lot of info of ports that have been removed.
I would like to suggest

1. moving the whole m_scheduler_group_port_info to Port struct and initialize it during port initialization or in this function.
2. or keeping in m_scheduler_group_port_info and removing items from it on port removing.

@neethajohn how do you think

[neethajohn]

I think the second solution will be a lot cleaner

[arvbb]

Hi Stephen/Neetha, I am not familiar with DPB. How is the port removal scenario handled currently for scheduler group? Is it already getting covered in existing code before this PR or it is new functionality that needs to be added? Please clarify, thanks.

[neethajohn]

@stephenxs, can you comment on the DPB scenario?

[stephenxs]

When it comes to DPB, I think what we care about is the port removal flow.
In short, the QoS orchagent should listen to the config_db.PORT table and handle the port removal event.
On receiving a port removal event, it should map the port name to OID and then erase the item indexed by the OID from m_scheduler_group_port_info.
I think we can use the function bool PortsOrch::getPort(string alias, Port &p) to map the port name to OID.
But what I'm not sure about is whether the mapping is still available in ports orch in the port removal scenario because there is no guarantee in terms of the order in which the orchagents (ports ~, QoS ~) handle the port removal notification.
this is why I proposed option #1. but if we want to use #2 maybe we also have a way. I will check with the DPB expert in my team (if there is one) and get back to you.
thanks.