On Tue, Jul 18, 2017 at 11:52 AM, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> On 07/18/17 19:20, Bill Fischofer wrote: > > 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. > > > > indexes might be not very multi hardware friendly. > I think we can do something similar to switchdev functions. Take a look > at kernel: > switchdev_port_fdb_add() > switchdev_port_fdb_del() > switchdev_port_fdb_dump() > I'm not quite sure why you think this may be the case. All we're saying is that a pktio is a logical interface that supports 1 or more MAC addresses that are indexed (per-pktio) from 0. How a given index gets mapped to HW resources that may be behind a pktio object is implementation-dependent. So this is really no different than a pktio device supporting multiple pktin or pktout queues, which are similarly indexed. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/ > linux.git/tree/net/switchdev/switchdev.c?h=v4.13-rc1 > > Maxim. > > > > > On Mon, Jul 17, 2017 at 3:09 AM, Bogdan Pricope < > 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> > >> wrote: > >>> > >>> > >>> On Fri, Jul 14, 2017 at 10:09 AM, Peltonen, Janne (Nokia - FI/Espoo) > >>> <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] > >>>> Sent: Friday, July 14, 2017 5:39 PM > >>>> To: Bogdan Pricope <bogdan.pric...@linaro.org>; Petri Savolainen > >>>> <petri.savolai...@linaro.org> > >>>> Cc: Narayana Prasad Athreya <pathr...@caviumnetworks.com>; Peltonen, > >> Janne > >>>> (Nokia - FI/Espoo) <janne.pelto...@nokia.com>; mcha...@cavium.com; > >>>> lng-odp@lists.linaro.org; pathr...@cavium.com; vattun...@cavium.com; > >>>> 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> 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 > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >
