On Fri, Jul 14, 2017 at 9:11 AM, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
> Hi, > > I think we need both MTU and MAC address to be settable from ODP. > > In OFP, at some point I was considering using tap pktio instead of ofp > tap interface for slow path processing - not being able to set MAC > address was A problem. > What about DHCP by MAC address? Maybe there are systems where > predefined MAC address is a requirement... don't know... > > MTU: what if default value is not 9K but something else? > I'll add this to the agenda for Monday's ARCH call. If Petri (+cc) wants to chime in before he leaves for vacation we'll take that input as well. > > BR, > Bogdan > > > On 14 July 2017 at 16:41, Narayana Prasad Athreya > <pathr...@caviumnetworks.com> wrote: > > Hi Bill > > The reasons below dont jive with what ODP does today. If the routines > > odp_pktio_mtu() and odp_pktio_mac_addr() exist today. They assume that > MTU > > can be configured and returned to the datapath. As an application > developer, > > it does make sense for me to use 2 different paths to talk to the same > > underlying device for the same setting - one path for configuring and one > > for reading the configuration. > > > > So from this standpoint the ODP should either support both get and set > > routines or not support either of them. > > > > On the control-plane vs data-plane debate, again as an application > > developer, my integrated application will need access to the underlying > > device for both control and data. If i am forced to right separate code > and > > potentially drivers for 2 paths, where is my incentive to use ODP API, > > because anyway i'm losing portability. > > > > Thanks > > Prasad > > > > On Friday 14 July 2017 06:33 PM, Bill Fischofer wrote: > >> > >> > >> > >> On Fri, Jul 14, 2017 at 6:05 AM, Peltonen, Janne (Nokia - FI/Espoo) > >> <janne.pelto...@nokia.com <mailto:janne.pelto...@nokia.com>> wrote: > >> > >> Hi, > >> > >> ODP API should somewhere define what exactly MTU means in the > >> context of ODP. > >> > >> One can guess that transmission and reception of L2 frames larger > >> than the > >> configured MTU is not guaranteed to succeed, but which bytes are > >> taken into > >> account? For instance, is Ethernet FCS counted towards the MTU? > >> > >> > >> We've had this discussion before. The whole concept of MTU is a bit of > an > >> anachronism from the early days of Ethernet. At speeds ODP is designed > for > >> (10Gb and above) all equipment should be running with jumbo frames (MTU > = > >> 9K). All equipment capable of running at these speeds is capable of this > >> size, and 9K is the recommended default MTU for this equipment. So > there's > >> really nothing one should need to control or change here. > >> > >> It would be interesting to understand the use case that is driving the > >> desire to be able to set MTU. > >> > >> The other consideration is that setting MTU (or MAC address) is a > control > >> plane function, not a data plane function. Just as the control plane > tells > >> the data plane which interfaces to use, the control plane is > responsible for > >> this type of configuration, as well as managing and responding to > >> configuration changes. So again, it would be good to understand the use > case > >> behind wanting to change these values in the data plane. > >> > >> > >> Janne > >> > >> > >> > -----Original Message----- > >> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org > >> <mailto:lng-odp-boun...@lists.linaro.org>] On Behalf Of Vamsi > Attunuru > >> > Sent: Friday, July 14, 2017 1:05 PM > >> > To: lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> > >> > Cc: mcha...@cavium.com <mailto:mcha...@cavium.com>; > >> pathr...@cavium.com <mailto:pathr...@cavium.com>; > >> vattun...@cavium.com <mailto:vattun...@cavium.com>; > >> sve...@cavium.com <mailto:sve...@cavium.com> > >> > Subject: [lng-odp] [API-NEXT PATCH v1 1/1] pktio APIs to set the > >> MAC address and MTU size. > >> > > >> > Adds new pktio APIs to set MTU and MAC address on pktio interface. > >> > > >> > Signed-off-by: Vamsi Attunuru <vattun...@cavium.com > >> <mailto:vattun...@cavium.com>> > >> > Signed-off-by: Mahipal Challa <mcha...@cavium.com > >> <mailto:mcha...@cavium.com>> > >> > Signed-off-by: Shally Verma <sve...@cavium.com > >> <mailto:sve...@cavium.com>> > >> > > >> > --- > >> > include/odp/api/spec/packet_io.h | 45 > >> ++++++++++++++++++++++++++++++++++++++++ > >> > >> > 1 file changed, 45 insertions(+) > >> > > >> > diff --git a/include/odp/api/spec/packet_io.h > >> b/include/odp/api/spec/packet_io.h > >> > index 8802089..1269f44 100644 > >> > --- a/include/odp/api/spec/packet_io.h > >> > +++ b/include/odp/api/spec/packet_io.h > >> > @@ -451,6 +451,10 @@ typedef union odp_pktio_set_op_t { > >> > struct { > >> > /** Promiscuous mode */ > >> > uint32_t promisc_mode : 1; > >> > + /** MAC address */ > >> > + uint32_t mac : 1; > >> > + /** MTU size */ > >> > + uint32_t mtu : 1; > >> > } op; > >> > /** All bits of the bit field structure. > >> > * This field can be used to set/clear all flags, or > bitwise > >> > @@ -482,6 +486,12 @@ typedef struct odp_pktio_capability_t { > >> > * A boolean to denote whether loop back mode is supported > >> on this > >> > * specific interface. */ > >> > odp_bool_t loop_supported; > >> > + > >> > + /** Maximum MTU size supported */ > >> > + uint32_t max_mtu_size; > >> > + > >> > + /** Length of MAC address supported on this specific > >> interface */ > >> > + uint32_t mac_addr_len; > >> > } odp_pktio_capability_t; > >> > > >> > /** > >> > @@ -912,6 +922,21 @@ int odp_pktout_send(odp_pktout_queue_t > >> queue, const odp_packet_t > >> > packets[], > >> > uint32_t odp_pktio_mtu(odp_pktio_t pktio); > >> > > >> > /** > >> > + * Set MTU value of a packet IO interface. > >> > + * > >> > + * Application should pass value upto max_mtu_size as indicated > by > >> > + * odp_pktio_capability_t:max_mtu_size. Any value beyond > >> max_mtu_size > >> > + * limit will result in failure. > >> > + * > >> > + * @param pktio Packet IO handle. > >> > + * @param mtu MTU value to be set. > >> > + * > >> > + * @return 0 on success > >> > + * @retval <0 on failure > >> > + */ > >> > +int odp_pktio_mtu_set(odp_pktio_t pktio, uint32_t mtu); > >> > + > >> > +/** > >> > * Enable/Disable promiscuous mode on a packet IO interface. > >> > * > >> > * @param[in] pktio Packet IO handle. > >> > @@ -946,6 +971,26 @@ int odp_pktio_promisc_mode(odp_pktio_t > pktio); > >> > int odp_pktio_mac_addr(odp_pktio_t pktio, void *mac_addr, int > >> size); > >> > > >> > /** > >> > + * Set the MAC address of a packet IO interface. > >> > + * > >> > + * Application should pass mac_addr buffer with size >= > >> > + * odp_pktio_capablity_t:mac_addr_len, size value less than > >> > + * implementation supported will result in API failure. > >> > + * > >> > + * On success, Implementation would read mac_addr buffer bytes > >> > + * upto mac_addr_len value indicated in capability information. > >> > + * > >> > + * @param pktio Packet IO handle > >> > + * @param mac_addr Pointer to MAC address to be set > >> > + * @param size Size of MAC address buffer > >> > + * > >> > + * @return 0 on success > >> > + * @retval <0 on failure > >> > + */ > >> > +int odp_pktio_mac_addr_set(odp_pktio_t pktio, const uint8_t > >> *mac_addr, > >> > + int size); > >> > + > >> > +/** > >> > * Setup per-port default class-of-service. > >> > * > >> > * @param[in] pktio Ingress port pktio handle. > >> > -- > >> > 1.9.3 > >> > >> > > >
