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. 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. Maxim. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/switchdev/switchdev.c?h=v4.13-rc1 > > <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 <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 > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >
