Thanks Bill for the details. We will work accordingly. Regards, Mahipal ________________________________ From: Bill Fischofer<mailto:bill.fischo...@linaro.org> Sent: 18-07-2017 09:50 PM To: Bogdan Pricope<mailto:bogdan.pric...@linaro.org> Cc: Peltonen, Janne (Nokia - FI/Espoo)<mailto:janne.pelto...@nokia.com>; Petri Savolainen<mailto:petri.savolai...@linaro.org>; Narayana, Prasad Athreya<mailto:prasadathreya.naray...@cavium.com>; Challa, Mahipal<mailto:mahipal.cha...@cavium.com>; lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>; Narayana, Prasad Athreya<mailto:prasadathreya.naray...@cavium.com>; Attunuru, Vamsi<mailto:vamsi.attun...@cavium.com>; Verma, Shally<mailto:shally.ve...@cavium.com> Subject: Re: [lng-odp] [API-NEXT PATCH v1 1/1] pktio APIs to set the MAC address and MTU size.
As agreed during today's ODP Public call: APIs for MTU capability and setting OK. Applications should remember that in most cases they will not be authorized to set the MTU since this relates to physical properties of the interface. odp_pktio_capability() should report number of mac addrs supported in addition to whether they are settable. odp_pktio_mac_addr_set() should take index value of which addr to set For compatibility may be better to leave odp_pktio_mac_addr() as is and by implication it retrieves mac addr 0. New API odp_pktio_mac_addr_get() can support explicit index. API patch can be merged separately but we still need reference implementation, validation test suite and documentation updates to make this eligible for release. On Mon, Jul 17, 2017 at 3:09 AM, Bogdan Pricope <bogdan.pric...@linaro.org<mailto:bogdan.pric...@linaro.org>> wrote: Hi, In DPDK case, default MTU is 1500: /* * Set the default MTU. */ eth_dev->data->mtu = ETHER_MTU; where: #define ETHER_MTU \ (ETHER_MAX_LEN - ETHER_HDR_LEN - ETHER_CRC_LEN) /**< Ethernet MTU. */ So, if you need to jumbo, you have to set MTU yourself (I guess dpdk will not send the frames otherwise): rte_eth_dev_set_mtu(pktio_entry->s.pkt_dpdk.portid, JUMBO_MTU_VALUE); So, it depends on how underneath SDK is working … BR, Bogdan On 14 July 2017 at 21:53, Bill Fischofer <bill.fischo...@linaro.org<mailto:bill.fischo...@linaro.org>> wrote: > > > On Fri, Jul 14, 2017 at 10:09 AM, Peltonen, Janne (Nokia - FI/Espoo) > <janne.pelto...@nokia.com<mailto:janne.pelto...@nokia.com>> wrote: >> >> Hi, >> >> >> >> I think MAC addresses and MTU are a bit different. >> >> >> >> There are valid use cases for application wanting to set the MAC address, >> even dynamically. For instance, with VRRP one wants to receive packets >> destined to a VRRP MAC address in addition to the fixed MAC address of a >> port. The possibility of configuring multiple MAC addresses (for the purpose >> of RX frame filtering) to the same port and changing them dynamically would >> be useful to some apps. >> >> The physical MTU of a port is more like a capability, the maximum that the >> port can do. The ODP application can then use any frame sizes it wants, up >> to the maximum size, without configuring anything to ODP. e.g. IP layer MTUs >> can be maintained by an IP stack application while the physical MTU at ODP >> level stays at the fixed maximum. An application does not have a need to >> tell ODP that the maximum frame size should be limited, but an ODP >> implementation might conceivably wish to get such information from the >> application or from elsewhere if supporting big frames (i.e. enabling jumbo >> frames) involves some costs that the ODP implementation would rather avoid >> if the application does not really need big frames. >> >> >> >> Even if MTU configuration is not added in ODP API, it is useful to be able >> to query the maximum physical MTU of a port as that can vary also among HW >> that supports pretty big frame sizes. The meaning of the returned MTU value >> (i.e. which bytes are counted) should be clarified. > > > I agree with this, however the historical reason for MTU was hardware > limits. When a driver transmits a packet, the physical MAC stores the bytes > of this packet in a FIFO (hardware registers) as the bits are clocked > through the PHY layer. Historically these registers were costly, so > minimizing them was important to meet needed price points. Today, as silicon > prices have fallen dramatically and even low-end processors have > multi-megabyte caches, there's little cost reasons for such low physical > limits. Moreover, at 10Gb and above speeds, you don't want to be filling the > pipe with IPG and framing bits, so larger packet sizes are inherently more > efficient. The result is that it's very difficult to fine a NIC in any > modern system that doesn't support jumbo frames, so the utility of setting > the MTU to anything other than 9K (especially for link speeds of interest to > ODP applications) is questionable. > >> >> >> >> Janne >> >> >> >> >> >> From: Bill Fischofer >> [mailto:bill.fischo...@linaro.org<mailto:bill.fischo...@linaro.org>] >> Sent: Friday, July 14, 2017 5:39 PM >> To: Bogdan Pricope >> <bogdan.pric...@linaro.org<mailto:bogdan.pric...@linaro.org>>; Petri >> Savolainen >> <petri.savolai...@linaro.org<mailto:petri.savolai...@linaro.org>> >> Cc: Narayana Prasad Athreya >> <pathr...@caviumnetworks.com<mailto:pathr...@caviumnetworks.com>>; Peltonen, >> Janne >> (Nokia - FI/Espoo) >> <janne.pelto...@nokia.com<mailto:janne.pelto...@nokia.com>>; >> mcha...@cavium.com<mailto:mcha...@cavium.com>; >> lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>; >> pathr...@cavium.com<mailto:pathr...@cavium.com>; >> vattun...@cavium.com<mailto:vattun...@cavium.com>; >> sve...@cavium.com<mailto:sve...@cavium.com> >> Subject: Re: [lng-odp] [API-NEXT PATCH v1 1/1] pktio APIs to set the MAC >> address and MTU size. >> >> >> >> >> >> >> >> On Fri, Jul 14, 2017 at 9:11 AM, Bogdan Pricope >> <bogdan.pric...@linaro.org<mailto: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<mailto: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> >> >> <mailto: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> >> >> >> >> <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> >> >> <mailto:lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>> >> >> > Cc: mcha...@cavium.com<mailto:mcha...@cavium.com> >> >> <mailto:mcha...@cavium.com<mailto:mcha...@cavium.com>>; >> >> pathr...@cavium.com<mailto:pathr...@cavium.com> >> >> <mailto:pathr...@cavium.com<mailto:pathr...@cavium.com>>; >> >> vattun...@cavium.com<mailto:vattun...@cavium.com> >> >> <mailto:vattun...@cavium.com<mailto:vattun...@cavium.com>>; >> >> sve...@cavium.com<mailto:sve...@cavium.com> >> >> <mailto: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> >> >> <mailto:vattun...@cavium.com<mailto:vattun...@cavium.com>>> >> >> > Signed-off-by: Mahipal Challa >> >> <mcha...@cavium.com<mailto:mcha...@cavium.com> >> >> <mailto:mcha...@cavium.com<mailto:mcha...@cavium.com>>> >> >> > Signed-off-by: Shally Verma >> >> <sve...@cavium.com<mailto:sve...@cavium.com> >> >> <mailto: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 >> >> >> >> >> > >> >> > >
