SAI Proposal for PoE #1977

DanielaMurin · 2024-03-06T13:34:16Z

The following proposal is a draft proposal to add PoE support that will
allow vendors to implement their own PoE solution.

rck-innovium · 2024-03-06T14:35:12Z

inc/saipoe.h

+     * @brief PoE port front panel ID
+     *
+     * @type sai_uint32_t
+     * @flags MANDATORY_ON_CREATE | CREATE ONLY


CREATE_ONLY. (underscore is missing)

Done, thanks.

rck-innovium · 2024-03-06T14:35:47Z

inc/saipoe.h

@@ -0,0 +1,524 @@
+/**
+ * Copyright 2024 Marvell.


Please fix the copyright.

Done, thanks.

rck-innovium · 2024-03-06T14:36:20Z

inc/saipoe.h

+ */
+typedef enum _sai_poe_device_type_limit_mode_t
+{
+    SAI_POE_DEVICE_LIMIT_MODE_TYPE_PORT_LIMIT = 0,


SAI_POE_DEVICE_TYPE_LIMIT_MODE_PORT_LIMIT instead of SAI_POE_DEVICE_LIMIT_MODE_TYPE_PORT_LIMIT

Done, thanks.

rck-innovium · 2024-03-06T14:38:03Z

inc/saipoe.h

+     * @brief PoE PSE ID (index)
+     *
+     * @type sai_uint32_t
+     * @flags MANDATORY_ON_CREATE | CREATE ONLY


CREATE_ONLY

Done, thanks.

rck-innovium · 2024-03-06T14:40:24Z

inc/saipoe.h

+        /**
+     * @brief temperature (in celsius) of the PSE
+     *
+     * @type int16_t


sai_int16_t

Done, thanks.

rck-innovium · 2024-03-06T14:42:10Z

inc/saipoe.h

+     *
+     * @type sai_uint32_t
+     * @flags CREATE_AND_SET
+     * @default maximum value that the port can provide


default can be left as a special value, say 0, to indicate that no max limit is enforced.

Done, thanks.

rck-innovium · 2024-03-06T14:45:29Z

inc/saitypes.h

+    SAI_POE_PORT_ACTIVE_CHANNEL_TYPE_A = 0,
+    SAI_POE_PORT_ACTIVE_CHANNEL_TYPE_B = 1,
+    SAI_POE_PORT_ACTIVE_CHANNEL_TYPE_A_AND_B = 2
+} sai_poe_port_active_channel_id_t;


either rename the typedef to: sai_poe_port_active_channel_type_t or the enums to SAI_POE_PORT_ACTIVE_CHANNEL_ID_A

Done, thanks.

rck-innovium · 2024-03-06T14:46:05Z

inc/saitypes.h

+{
+    SAI_POE_PORT_SIGNATURE_TYPE_SINGLE = 0,
+    SAI_POE_PORT_SIGNATURE_TYPE_DUAL = 1
+} sai_poe_port_signature_type_id_t;


please rename the typedef to sai_poe_port_signature_type_t

Done, thanks.

rck-innovium · 2024-03-06T14:46:29Z

inc/saitypes.h

+{
+    SAI_POE_PORT_CLASS_METHOD_TYPE_REGULAR = 0,
+    SAI_POE_PORT_CLASS_METHOD_TYPE_AUTO_CLASS = 1
+} sai_poe_port_class_method_id_t;


sai_poe_port_class_method_id_t => sai_poe_port_class_method_type_t

Done, thanks.

rck-innovium · 2024-03-06T14:50:23Z

inc/saipoe.h

+     * @type sai_object_id_t
+     * @flags MANDATORY_ON_CREATE | CREATE_ONLY
+     */
+    SAI_POE_ATTR_DEVICE_ID = SAI_POE_PORT_ATTR_START,


SAI_POE_PORT_ATTR_DEVICE_ID

Done, thanks.

inc/saitypes.h

kcudnik · 2024-03-06T14:52:56Z

Please fix build errors

kcudnik · 2024-03-07T10:07:38Z

inc/saitypes.h

+    uint32_t voltage_in_mv;
+
+    /**
+     * @brief current in milliAmpere
+     */
+    uint32_t current_in_ma;
+
+    /**
+     * @brief consumption in milliWatts
+     */
+    uint32_t consumption_in_mw;
+


please remove units from vairable names

also is power consumption not needed information ? you can calculate this multiplying A and V to het Watts, but maybe there is some other meaning of this ?
also not sure what are the expected ranges between voltage and current are 40-50 volts ?

I'll remove them. :)

Theoretically yes, you can calculate the Watts. However, we need to also take into consideration the power loss that happens because of the cable length and other hardware components/designs. So, when we multiple A and V we get a number that is in the ballpark but not completely accurate. This is why we prefer to add a dedicated consumption field.

As for the second question, the expected ranges are based on the PoE class. Each class supports up to a certain number of watts. Here is a chart that has the ranges:

The PSE is the power sourcing equipment, and the PD is a powered device (phone, camera, access points)

Yes. That's correct. We need to account the power conversion factors.
Power = current * voltage * power_factor
Here the power factor could be 80% to 85%.
The PSE reports the power at it's side. It means the power that the PSE is delivering. This doesn't include the power loss due to cable medium and length. The loss is accounted at PD side.
So please keep the power value fetched from the PoE controller that is accurate.

I am keeping the power value/consumption field. :)

kcudnik · 2024-03-07T10:28:48Z

please fix build errors, you have a lot of warnings https://dev.azure.com/mssonic/build/_build/results?buildId=493535&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=1f6d5e21-f0ce-508d-13df-d1c50f7ea7b9&l=286 you will also need to squash commits to 1 commit, since each commit is processed separatly, please try to fix all errors locally, and then submit, you just need to type "make" in meta directory to see if build is correct

DanielaMurin · 2024-03-07T11:00:40Z

@kcudnik
Thanks for the info! Will do. :)

inc/saiswitch.h

andriy-kokhan · 2024-03-12T07:31:55Z

inc/saiswitch.h

+     * @allownull true
+     * @default SAI_NULL_OBJECT_ID
+     */
+    SAI_SWITCH_ATTR_POE_DEVICE_ID,


Looks like it's proposed to have one-to-one mapping of SAI_OBJECT_TYPE_POE_DEVICE to SAI_OBJECT_TYPE_SWITCH, correct?

Looking at it again, perhaps SAI_OBJECT_TYPE_POE_DEVICE should not be mapped to SAI_OBJECT_TYPE_SWITCH at all. Since PoE has its own software and hardware that is separated.

In general, other use-cases (like PHY or Fabric/VoQ) use a switch object for slightly different reasons. E.g., PHY use case considers PHY as L1 Switch object which makes sense. From what I understand, that's not the case with PoE which uses switch object just as a container or as an entry point for PoE specific syncd application instance to create PoE abstraction.

Looking at it again, perhaps SAI_OBJECT_TYPE_POE_DEVICE should not be mapped to SAI_OBJECT_TYPE_SWITCH at all. Since PoE has its own software and hardware that is separated.

Yes. The PoE controller HW is entirely different from switch silicon. The switch (MAC device) and the PoE controllers are entirely different HW elements. The device Id for PoE controllers is different from the MAC/PHY device Id/type.

andriy-kokhan · 2024-03-12T07:35:12Z

inc/saipoe.h

+     * @type sai_uint32_t
+     * @flags MANDATORY_ON_CREATE | CREATE_ONLY
+     */
+    SAI_POE_PORT_ATTR_FRONT_PANEL_ID = SAI_POE_PORT_ATTR_START,


Is it the same as SAI_PORT_ATTR_HW_LANE_LIST ? If so, should we add | KEY as well?

* @type sai_u32_list_t * @flags MANDATORY_ON_CREATE | CREATE_ONLY | KEY */ SAI_PORT_ATTR_HW_LANE_LIST,

Can we have a single POE port that uses multiple HW lanes?

The front panel port can have a mapping of one-to-one or one-to-many (one front panel port, many power lines that supply electricity). However, the front panel port needs to work as one port. Meaning that if a configuration is set on the PoE port (port power priority, disable power delivery, etc...) all of the power lines that are connected to that port will receive this configuration.
In our case, and what is usually done, there is an internal PoE port matrix that is binds the ports to their hardware components (physical ports). The SAI implementation should decide how to map the ports internally according to the specific board.

Please look at the visual design below, specifically PSE N:

Since PoE works with copper ethernet cables, it does not support port breakout or aggregation.

The above diagram has a few glitches. The PSE ports are p1 ... pN. Here the N could be 4 or 8. This is subject to the PoE chip and the supported PoE mode of operations like AT, BT-Type3, BT-full (Both Type-3, Type-4).
Similarly the Host CPU to PoE MCU interface could be Shared Memory/UART/I2C/SPI etc. It is subject to the platform and the implementation.

In general, the image wasn't generic enough. It was updated in PoE_Physical_Design.png to reflect something less constrictive.

kcudnik · 2024-03-12T08:57:07Z

you don't need to explicitly set value to enums if they are in continuous form

kcudnik · 2024-03-14T17:53:05Z

ASSERT FAILED (on line 5131): object SAI_OBJECT_TYPE_POE_DEVICE is disconnected from graph

that error means that there is no other dependency on this object on other objects, that means that dependency graph is disconnected, you would need to add a link from existing objects, for example use any existing object in that specific object type poe_device to have a link established in dependency or we could discuss exception on this case

DanielaMurin · 2024-03-17T10:24:10Z

I've added the object into sai_switch_attr_t, as an entry point. Adding exceptions may cause an unwanted ripple effect.

kcudnik · 2024-03-17T11:30:06Z

I've added the object into sai_switch_attr_t, as an entry point. Adding exceptions may cause an unwanted ripple effect.

what ripple effect, what will it cause ?

DanielaMurin · 2024-03-17T14:02:46Z

In general, if we don't need to use an exception it's best not to, so I think it would probably be better to link to an existing object.
From my point of view, I'm open to both approaches.

Are there any objects that were given exceptions?

kcudnik · 2024-03-17T14:46:54Z

Yes 1, debug counter

lguohan · 2024-03-18T16:00:57Z

doc/SAI-Proposal-PoE.md

+    SAI_SWITCH_TYPE_FABRIC,
+
+    /** Switch type is PoE (Power over Ethernet) */
+    SAI_SWITCH_TYPE_POE,


why is this a new type of switch?

what is the purpose of this "SAI_SWITCH_TYPE_POE" ? Does this mean the switch is PoE capable and can deliver power via it's port?

Yes.

If the switch and PoE vendors differ than we want to provide flexibility to create two instances for each functionality. (Different hardware, two different vendors, two different implementations)
For example, if vendor A already has a SAI implementation and they want external PoE support, they can keep using their solution and add another PoE implementation from vendor B.

(If the same vendor provides a NPU and PoE switch, then it can be placed under NPU switch with PoE abilities.
Per the community's request, I added a new PoE attribute to sai port: SAI_PORT_ATTR_POE_PORT_ID)

kcudnik · 2024-03-18T16:08:37Z

inc/saiswitch.h

@@ -310,6 +310,9 @@ typedef enum _sai_switch_type_t
    /** Switch type is Fabric switch device */
    SAI_SWITCH_TYPE_FABRIC,

+    /** Switch type is POE (Power over Ethernet) */
+    SAI_SWITCH_TYPE_POE,


i think this we would need to discuss, this on SAI community meeting, i think this is fine, but i think this is more like ability, since for example maybe NPU switch could have some ethernet ports that supports PoE, not sure if any exists, but i think we could discuss this, i think PoE is more like a "feature" of the switch, rather then entire switch on its own, but maybe i could be wrong

DanielaMurin · 2024-03-19T14:40:04Z

@lguohan @kcudnik
If the same vendor provides a NPU and PoE switch, then it can be placed under NPU switch with PoE abilities like Kamil mentioned.
However, if the switch and PoE vendors differ than we want to provide flexibility to create two instances for each functionality. (Two different hardwares, two different vendors, two different implementations)
For example, if vendor A already has a SAI implementation and they want external PoE support, they can keep using their solution and add another PoE implementation from vendor B.

rck-innovium

Looks good based on the review in the SAI community meeting on 21/Mar/2024.

Please consider Taras and Jai's suggestion of having the below:

    /**
     * @brief On NPUs that support POE, read the associated POE Port Id.
     *
     * @type sai_object_id_t
     * @flags READ_ONLY
     * @objects SAI_OBJECT_TYPE_POE_PORT
     * @allownull true
     * @default SAI_NULL_OBJECT_ID
     */
    SAI_PORT_ATTR_POE_PORT_ID

DanielaMurin · 2024-03-24T17:39:31Z

Thanks Ravi, I've added it. :)

kcudnik · 2024-03-25T04:56:19Z

inc/saiswitch.h

@@ -3000,6 +3003,19 @@ typedef enum _sai_switch_attr_t
     */
    SAI_SWITCH_ATTR_AVAILABLE_SYSTEM_VOQS,

+    /**
+     * @brief POE DEVICE LIST
+     *


No need for all capital letters here

rk946043 · 2024-04-02T06:46:18Z

doc/SAI-Proposal-PoE.md

+
+| **Term** | **Definition**                                                                              |
+| -------------- | ------------------------------------------------------------------------------------------------- |
+| PoE            | Power over Ether                                                                                  |


Power Over Ethernet

DanielaMurin · 2024-04-02T07:47:06Z

@kcudnik
Hi Kamil, is there anything from my side that I can do to help move things along?

kcudnik · 2024-04-02T08:22:07Z

if everything is set, we can merge this

DanielaMurin · 2024-04-02T08:33:12Z

From my side, everything is set.
(All questions were answered. and all requests have been added.)

rk946043 · 2024-04-02T09:13:04Z

doc/SAI-Proposal-PoE.md

+
+# Overview
+
+Power over Ethernet, or PoE, describes any of several standards that pass electric power along with data on twisted-pair Ethernet cabling. This allows a single cable to provide both a data connection and enough electricity to power networked devices such as wireless access points (WAPs), IP cameras and VoIP phones.


Reframe the sentence as shown below:

Power over Ethernet, or PoE, describes any of the 802.3(AF, AT, BT) standards that deliver electrical power along with data on twisted-pair Ethernet cables. This allows a single cable to provide both data connection and electricity to power the networked devices such as wireless access points (WAPs), IP cameras and VoIP phones etc.

rk946043 · 2024-04-02T09:15:06Z

doc/SAI-Proposal-PoE.md

+# Key Ideas behind PoE
+
+1. PoE provides a hardware solution for providing a data connection and electricity to power connected devices
+2. The PoE software delivers information about the board and its operational statuses


The PoE software provides an interface to configure(program) and query the PoE controller and its internal peripherals such as ports etc.

DanielaMurin · 2024-04-02T09:27:37Z

As per @rk946043's request, I've updated some sentence structures in the proposal MD file.

rk946043 · 2024-04-02T09:30:51Z

doc/SAI-Proposal-PoE.md

+
+### PoE Device ID
+
+This object is used to hold the global configuration and PoE hardware status. In many cases, one PoE device instance will have access to all the PoE hardware and components.


There can be more than one PoE controller units on a board. Does this ID serve that purpose?

The PoE device represents the PoE subsystem(s).
It can be a singleton, or you can make as many SAI_OBJECT_TYPE_POE_DEVICE objects as required by your system.

rk946043 · 2024-04-02T09:32:09Z

doc/SAI-Proposal-PoE.md

+
+### PoE PSE ID
+
+This object is used to access data from the Power Sourcing Equipment devices in the board. Such as PSE temperatures, versions, and statuses. There can be multiple PSEs in one board.


Do you allow independently monitor each of the PSE chips underneath the PoE MCU under the PoE controllers?

You create a SAI_OBJECT_TYPE_POE_PSE object and through its existing attributes you access the information for that specific PSE.
If you want to manage the PSE devices, you should create them as a PoE device object.

In most of the times, the PSE chip is underneath the PoE MCU. The MCU manages all the PSE chips. The PSE chips are abstracted under MCU. Here the PoE controller (MCU + PSE chips) is considered as a single unit that manages all the ports underneath it.

MCU based Design:

| --> PSE1

CPU <---> MCU <-->| --> PSE2
.........
| --> PSEn

MCU less Design:

| --> PSE1

CPU <---> | --> PSE2
.........
| --> PSEn

Ultimately the POE controller and the Ports are the primary objects that deal with PoE functionality.
Which design you are targeting here?
If non MCU design is considered, The CPU core has more job like triggering init sequence (reset, push firmware image), configurations, state monitoring etc. In such cases the design MUST cater to these scenarios.

The PoE device object and the PSE object are two different objects and are not considered a single unit.

What you wrote is exactly the design. The PoE controller which is the PoE device object, and the ports which is the PoE port object are indeed the main functionality.

The PSE object has read-only attributes and is not used for management. For management, the PoE device object is used, “PoE controller” as you called it.
The PSE object is not mandatory. So, if it is not relevant to the PoE solution then it does not need to be created.

Creating the PoE device object(s), is what triggers initialization sequence. The sequence is completely internal. It should not affect SAI.

The objects allow both MCU based and MCU “less” designs.
For non-MCU, the firmware is loaded by the switch object. (Assuming all the PSEs use the same firmware)
For internal state monitoring, this should be handled inside the SAI SDK and does not require any SAI APIs.
The implementation is up to the vendor, they can initialize everything however they see fit. And then SAI objects are used to interact with the higher levels. (NOS)

rk946043 · 2024-04-02T10:15:40Z

doc/SAI-Proposal-PoE.md

+    SAI_SWITCH_TYPE_FABRIC,
+
+    /** Switch type is PoE (Power over Ethernet) */
+    SAI_SWITCH_TYPE_POE,


rk946043 · 2024-04-02T11:05:49Z

doc/SAI-Proposal-PoE.md

+     * @flags CREATE_ONLY
+     * @default ""
+     */
+    SAI_POE_DEVICE_ATTR_HARDWARE_INFO = SAI_POE_DEVICE_ATTR_START,


Does this attribute SAI_POE_DEVICE_ATTR_HARDWARE_INFO refer to initializing the PoE controller ? If so, it is very misleading.

The SAI_POE_DEVICE_ATTR_HARDWARE_INFO refers to initializing the PoE subsystem according to the PoE hardware.
For example, if the board has a MCU you can set the hw_info to "integrated_mcu". If the device uses direct i2c access then you can set the hw_info to "i2c" or an address. You can also send an empty string if this is not relevant for the sytem.
This allows the driver to understand how to communicate with the PoE hardware.

rk946043 · 2024-04-02T11:12:14Z

doc/SAI-Proposal-PoE.md

+strncpy(attr.value.chardata, "integrated-mcu", sizeof("integrated-mcu");  /* string is only relevant to the driver, can be anything*/ 
+
+attr_count = 1;
+sai_create_poe_device_fn(&poe_device_id, switch_id, attr_count, attr_list);


A Switch(MAC) device can have multiple ports and these ports can span across multiple PoE controllers like as shown below:
ports 1 ... K |---------- PoE Controller1
MAC --- ports K ... M |---------- PoE Controller2
ports M ... N |---------- PoE Controller3
and so on
Like some 'J' PoE controllers are serving 1 ... N ports of MAC(Switch) device.
We need the switch Id and the PoE controller (instance) Id here for initializing all the PoE devices under a switch.

In our example, we have a microcontroller chip that runs PoE firmware (manages all PSE controllers), and the system only communicates with the MCU and not directly with all the PoE components.
If you wish to control each PoE controller individually, please create a PoE device for each relevant one.

rk946043 · 2024-04-05T07:08:40Z

doc/figures/PoE_Physical_Design.png

Keep an MCU between Host CPU and the PSE chips.
You may keep a box with dotted lines indicating an optional MCU presence.

I prefer not to add an MCU since not all designs have one and it may cause confusion.
The simplistic example above shows the flexibility, while highlighting the new SAI components.

Since this document doesn't comment anything about MCU between the host CPU and PSEs, I advise you to keep an MCU with dotted lines indicating that MCU presence is optional and also mention the MCU based and MCU less model in the document.

JaiOCP

Looks Good

tjchadaga · 2024-04-11T21:29:44Z

@prgeor - could you please help review as well?

kcudnik · 2024-04-12T07:08:24Z

please resolve conflicts

rlhui · 2024-04-12T21:47:20Z

@DanielaMurin - are you able to resolve conflicts by today (4/12 PST)?

DanielaMurin · 2024-04-14T07:10:11Z

@rlhui @kcudnik
I've resolved the merge conflicts, thank you.

tjchadaga · 2024-04-16T21:36:45Z

/azp run

azure-pipelines · 2024-04-16T21:36:50Z

Commenter does not have sufficient privileges for PR 1977 in repo opencomputeproject/SAI

rlhui · 2024-04-17T01:13:49Z

/azp run

azure-pipelines · 2024-04-17T01:13:57Z

Azure Pipelines successfully started running 1 pipeline(s).

rlhui · 2024-04-17T02:22:08Z

PR build failed.

The following proposal is a draft proposal to add PoE support that will allow vendors to implement their own PoE solution. Change-Id: I73fe13f2aceba1ed26bb7f23e480c99f2feefd73 Signed-off-by: DanielaMurin <dmurin@marvell.com>

DanielaMurin · 2024-04-17T07:05:34Z

Hi Rita, I rebased it, all checks have passed. Thank you, Daniela From: Rita Hui ***@***.***> Sent: Wednesday, April 17, 2024 5:23 AM To: opencomputeproject/SAI ***@***.***> Cc: Daniela Murin ***@***.***>; Mention ***@***.***> Subject: [EXTERNAL] Re: [opencomputeproject/SAI] SAI Proposal for PoE (PR #1977) Prioritize security for external emails: Confirm sender and content safety before clicking links or opening attachments

…

________________________________ PR build failed. — Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_opencomputeproject_SAI_pull_1977-23issuecomment-2D2060220547&d=DwMCaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=ySfoP2THkroSqxTCBAs9iWFF4apXUmRGBxILxzbG3lo&m=KRO8I55bAheFGOjv3Caq6cA5sC_UN5zGBh2nNgCK5EbyBxyuMBPLJtU0giGzcakd&s=943gLbdYsNVfU4AD-6dx5wZMZDeWlnPZM2my_wjOsHw&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AKIYGLPUVZ2DOK4QSLU4RB3Y5XMGNAVCNFSM6AAAAABEJCLGWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRQGIZDANJUG4&d=DwMCaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=ySfoP2THkroSqxTCBAs9iWFF4apXUmRGBxILxzbG3lo&m=KRO8I55bAheFGOjv3Caq6cA5sC_UN5zGBh2nNgCK5EbyBxyuMBPLJtU0giGzcakd&s=0dzTf3siTTmDm_fSujC04tp2yTLOftHNQRGjmx7m_aQ&e=>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

kcudnik · 2024-04-17T12:53:59Z

inc/saipoe.h

+     * Format is vendor specific.
+     * Example: Like PCI location, I2C address, UART etc.
+     *
+     * @type char


this will point to sai_attribute_value_t.chardata[32] type, is that what you want ?

Yes, a string allows each vendor the flexibility to pass whatever information they need on how to communicate with the PoE hardware.
For example, if the board has a MCU you can set the hw_info to "integrated_mcu". If the board uses direct i2c access then you can set the hw_info to "i2c" or an address. You can also send an empty string if this is not relevant for the system.

A simple string will not be sufficient. Better define a model for possible interfaces.

UART :
Dev name/node, baud rate, parity settings etc

I2C:
Bus number, i2C address and the mode of I2C/SMBUS transaction etc

SPI:
SPI address, CS, Cpol, Cphase etc

PCI or shared memory:
Memory start, Memory size, R/W attributes, etc
and so on.

Proposal to add PoE support that will allow vendors to implement their own PoE solution. Signed-off-by: DanielaMurin <dmurin@marvell.com> Signed-off-by: Sid Ukidve <sidharaj-u.ukidve@broadcom.com>

DanielaMurin force-pushed the sai-poe-proposal branch from 01b5936 to 7dfd845 Compare March 6, 2024 13:43

rck-innovium suggested changes Mar 6, 2024

View reviewed changes

kcudnik reviewed Mar 6, 2024

View reviewed changes

inc/saitypes.h Outdated Show resolved Hide resolved

kcudnik reviewed Mar 7, 2024

View reviewed changes

DanielaMurin force-pushed the sai-poe-proposal branch 2 times, most recently from ae00d09 to 37d7a61 Compare March 11, 2024 12:40

plvisiondevs mentioned this pull request Mar 11, 2024

PoE design proposal HLD document sonic-net/SONiC#1631

Open

andriy-kokhan reviewed Mar 12, 2024

View reviewed changes

inc/saiswitch.h Show resolved Hide resolved

andriy-kokhan reviewed Mar 12, 2024

View reviewed changes

DanielaMurin force-pushed the sai-poe-proposal branch from 37d7a61 to 218e3e7 Compare March 14, 2024 15:21

DanielaMurin force-pushed the sai-poe-proposal branch from 218e3e7 to 833e3a5 Compare March 17, 2024 10:13

lguohan reviewed Mar 18, 2024

View reviewed changes

kcudnik reviewed Mar 18, 2024

View reviewed changes

DanielaMurin force-pushed the sai-poe-proposal branch 2 times, most recently from f0ea0c5 to 1f4909e Compare March 21, 2024 10:49

rck-innovium approved these changes Mar 21, 2024

View reviewed changes

DanielaMurin force-pushed the sai-poe-proposal branch from 1f4909e to f4d23cb Compare March 24, 2024 17:37

kcudnik reviewed Mar 25, 2024

View reviewed changes

rk946043 reviewed Apr 2, 2024

View reviewed changes

DanielaMurin force-pushed the sai-poe-proposal branch from 99f7a12 to 5f94ac9 Compare April 2, 2024 09:25

rk946043 reviewed Apr 2, 2024

View reviewed changes

rk946043 reviewed Apr 5, 2024

View reviewed changes

JaiOCP approved these changes Apr 11, 2024

View reviewed changes

DanielaMurin force-pushed the sai-poe-proposal branch 2 times, most recently from a859124 to 67dca1c Compare April 14, 2024 06:40

SAI Proposal for PoE Support

17fc43c

The following proposal is a draft proposal to add PoE support that will allow vendors to implement their own PoE solution. Change-Id: I73fe13f2aceba1ed26bb7f23e480c99f2feefd73 Signed-off-by: DanielaMurin <dmurin@marvell.com>

DanielaMurin force-pushed the sai-poe-proposal branch from 67dca1c to 17fc43c Compare April 17, 2024 06:57

kcudnik reviewed Apr 17, 2024

View reviewed changes

rlhui merged commit 2587c3b into opencomputeproject:master Apr 17, 2024
3 checks passed


		# Overview

		Power over Ethernet, or PoE, describes any of several standards that pass electric power along with data on twisted-pair Ethernet cabling. This allows a single cable to provide both a data connection and enough electricity to power networked devices such as wireless access points (WAPs), IP cameras and VoIP phones.


		### PoE Device ID

		This object is used to hold the global configuration and PoE hardware status. In many cases, one PoE device instance will have access to all the PoE hardware and components.


		### PoE PSE ID

		This object is used to access data from the Power Sourcing Equipment devices in the board. Such as PSE temperatures, versions, and statuses. There can be multiple PSEs in one board.

SAI Proposal for PoE #1977

SAI Proposal for PoE #1977

Conversation

DanielaMurin commented Mar 6, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kcudnik commented Mar 6, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DanielaMurin Mar 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kcudnik commented Mar 7, 2024

DanielaMurin commented Mar 7, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andriy-kokhan Mar 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kcudnik commented Mar 12, 2024

kcudnik commented Mar 14, 2024

DanielaMurin commented Mar 17, 2024

kcudnik commented Mar 17, 2024

DanielaMurin commented Mar 17, 2024

kcudnik commented Mar 17, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DanielaMurin commented Mar 19, 2024

rck-innovium left a comment

Choose a reason for hiding this comment

DanielaMurin commented Mar 24, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DanielaMurin commented Apr 2, 2024

kcudnik commented Apr 2, 2024

DanielaMurin commented Apr 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DanielaMurin commented Apr 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MCU based Design:

MCU less Design:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DanielaMurin Mar 7, 2024 •

edited

Loading

andriy-kokhan Mar 12, 2024 •

edited

Loading