On 19 July 2017 at 01:13, Bill Fischofer <bill.fischo...@linaro.org> wrote:
> > > On Tue, Jul 18, 2017 at 2:42 PM, Maxim Uvarov <maxim.uva...@linaro.org> > wrote: > >> On 07/18/17 21:24, Bill Fischofer wrote: >> > >> > >> > On Tue, Jul 18, 2017 at 11:52 AM, Maxim Uvarov <maxim.uva...@linaro.org >> > <mailto: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. >> > >> >> I assume that in many cases pktio can have hw switch under it. To accept >> packets you need to learn switch with mac addresses which it can >> bypass. That is regarding unicast and multicast. For example your >> unicast mac is 1:2:3:4:5:6 but you also want to get broadcasts for >> example ptp 01:1B:19:00:00:00 and for example STP 01:80:C2:00:00:00 and >> if it's ipv4 then you need to subscribe to ipv4 multicasts >> 01:00:5E:00:00:00. So if hardware allows - you can load that macs into >> it. That's looks like a valid use case and no need to switch to >> promiscuous mode. >> > > One of the use-cases for ODP is the ODP app itself is a switch, so each > pktio object is just a port on that switch. But yes, the main use case for > multiple MAC addrs is for finer-grained control than putting the pktio into > promiscuous mode. > > >> >> I assume that ports on some chips can be switched to learning mode. In >> that case they will fill their fdbs in hardware without software assist. >> And mapping them to software is not that case. Btw how does application >> will use that index? I think index is useless and add(), remove(), >> dump() is enough. One use case might be it's different pktio queues or >> index injected to packet header for more quick decision where to route >> that packet. So I would add less restrictions until there is real use >> case for that. >> > > If the pktio has populated its MAC addresses independent of the ODP app, > then the app would get those by reading them with odp_pktio_mac_addr_get(). > Without an index, how would you replace one MAC addr without disturbing any > of the others? > by value? del(1:2:3:4:5:6) add(1:2:3:4:5:7) > > >> >> Maxim. >> >> > >> > >> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/li >> nux.git/tree/net/switchdev/switchdev.c?h=v4.13-rc1 >> > <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l >> inux.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 <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.savolainen@linar >> o.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_que >> ue_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_pkt >> io_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 >> > >>>>>> >> > >>>>>> >> > >>>>> >> > >>>> >> > >>>> >> > >>> >> > >>> >> > >> >> > >> > >> >> >
