Did you see RFC 3635?
> -----Original Message----- > From: lng-odp [mailto:[email protected]] On Behalf Of EXT > Maxim Uvarov > Sent: Monday, October 19, 2015 7:25 PM > To: [email protected] > Subject: [lng-odp] [PATCHv3] api: pktio link > > Define API to get pktio link state: seed and link up/down. > > Signed-off-by: Maxim Uvarov <[email protected]> > --- > v3: - even more simple, left only link up/down state and speed. > v2: - use simple struct to return pktio link state; > - odp will not modify link, only ready it's state; > > include/odp/api/packet_io.h | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h > index 3479af1..2fa3db8 100644 > --- a/include/odp/api/packet_io.h > +++ b/include/odp/api/packet_io.h > @@ -96,6 +96,25 @@ typedef struct odp_pktio_param_t { > } odp_pktio_param_t; > > /** > + * Packet IO link state information > + */ > +typedef struct odp_pktio_link_state_t { > + uint32_t speed; /**< Speed in Mbps: 10, 100, 1000 etc */ uint32_t speed_mbps; // Speed in Mbps. This leaves room for speed_bps which would support odd link speeds. RFC specifies that lower speed links are bps and higher Mbps, but I think it better to be explicit on the units. > + odp_bool_t up; /**< 1 - link up, 0 - link down */ Up is not good name for link status. RFC 3635 defines more than operational status values (ifOperStatus). We need to be prepared for that. Bool is informative enough if you need to report that "link is not up although user did try to set it up because a piece of HW is missing == it will not get up before you plug in the missing piece == not_present". uint8_t/int8_t/enum status; // 1: link up, 0: down, -1 not_present (== ifOperStatus ) typedef struct odp_pktio_link_state_t { uint8_t type; // 0: Ethernet (or enum ODP_PKTIO_ETHERNET), ... OK. This is not link state, but we need link type defined somewhere in interface level info. Also the RFC defines "interface type == ETHERNET". uint8_t status; // 1: link up, 0: down, -1 not_present (== ifOperStatus ) uint8_t autoneg; // 1: autoneg on, 0: off, -1: not supported Would give hint to the user why e.g. link speed is not always the same, it depends on the other side of the link. uint8_t duplex; // 1: full duplex, 0: half duplex Property of a physical layer. May be not too interesting when using the interface, but could be useful to print out when debugging link problems (did someone plug my 1 Gbps link to an old "Fast Ethernet hub" and the port did autoneg to 100 Mbps + half duplex) uint32_t speed_mbps; // Speed in Mbps. This leaves room for // speed_bps which would support odd (Mbps) link speeds uint32_t mtu; // MTU in bytes This is a link property and also defined by the RFC. Interface cannot dictate MTU, it depends on link type and capability on the other side of the link. } odp_pktio_link_state_t; All these properties are needed pretty rarely, so I think a struct better than 5 individual calls. It's also easier to extend later (add more fields). Then those fields that are needed very often can be offered as additional function calls. Addresses (including promiscuous mode) are interface level data, but not so straight forward since it's mixed with classification. -Petri > +} odp_pktio_link_state_t; > + > +/** > + * Get packet IO link state > + * > + * @param[in] pktio Packet IO handle > + * @param[out] state Buffer to save link state > + * > + * @retval 0 on success (state info updated) > + * @retval <0 on failure (state info not updated) > + */ > +int odp_pktio_link_state(odp_pktio_t pktio, odp_pktio_link_state_t > *state); > + > +/** > * Open a packet IO interface > * > * An ODP program can open a single packet IO interface per device, > attempts > -- > 1.9.1 > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
