/openbmc/bmcweb/redfish-core/lib/ |
H A D | roles.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | thermal.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | service_root.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | power.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | redfish_sessions.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | network_protocol.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | chassis.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | ethernet.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | update_service.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | managers.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | account_service.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | systems.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
H A D | log_services.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
/openbmc/bmcweb/redfish-core/include/ |
H A D | redfish.hpp | 0f74e643 Mon Nov 12 17:17:05 CST 2018 Ed Tanous <ed.tanous@intel.com> bmcweb: Redfish away from json cache In the original incarnation of bmcweb, route registration was done automatically. This has proved to be a terrible idea, wraught with corner cases and issues. The route registration is currently the only user of the redfish::Node::json element. Unfortunately, as written, this structure consumes a lot of memory that's duplicated and not very useful. From a performance perspective, there is almost no difference between rebuilding the structure for each GET request, and having the "cache" that needs to be copied into the response and modified before it can be useful. In the programming tradeoffs for bmc, lower memory usage is more important than latency, especially at these levels. Change-Id: I785e8352123e5e886acf05cd59cb23648f93839d Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|