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? > > 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.savolainen@ > 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 > > >>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>>> > > >>> > > >>> > > >> > > > > > >
