Added ControlRecommender interface

[lhlawson]

Signed-off-by: Lowren Lawson lowren.h.lawson@intel.com

• Relates to As a GEOPM developer I would like a recommender class for controls #2791 story from github issues
• Fixes #Recommender Interface PR based upon arch review feedback #2794 change request from github issues.

Updated recommender class interface #2792 based upon review #2793

[cmcantalupo]

why not just?

/*                                                                                                                                                                                 
 * Copyright (c) 2015 - 2022, Intel Corporation                                                                                                                                    
 * SPDX-License-Identifier: BSD-3-Clause                                                                                                                                           
 */

#ifndef CONTROLRECOMMENDER_HPP_INCLUDE
#define CONTROLRECOMMENDER_HPP_INCLUDE

#include <memory>
#include <vector>
#include <string>

struct geopm_request_s;

namespace geopm
{
    class ControlRecommender
    {
        public:
            ControlRecommender() = default;
            virtual ~ControlRecommender() = default;
            static std::unique_ptr<ControlRecommender> make_unique(std::string algorithm, std::vector<geopm_request_s> control_requests);
            virtual void update(void) = 0;
            virtual std::vector<double> settings(void) = 0;
            virtual void performance_bias(double bias) = 0;
    };
}

#endif

[cmcantalupo]

supported_requests -> set_configured_requests()
supported_requests const -> get_configured_requests() const

[cmcantalupo]

This API is insufficient to enable an agent to express information that is gathered from the TreeComm. There is no way to have the ControlRecommender send data to other nodes via the TreeComm. This makes it difficult for distributed agent algorithms to fit into this API.

[dannosliwcd]

Some additional context from that discussion:

In the meeting we discussed one solution may be for control recommenders to describe things that they'd send over TreeComm. We noted that TreeComm needs to know information about what it will communicate early in launch (i.e., how much space to allocate for samples and policies). If we go that direction, it might be worth evaluating whether there are any communication overhead aspects to consider (e.g., whether we also need to independently enable/disable communicators associated with different recommenders)