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
>> >>
>> >>
>> >
>>
>>
>
>

Reply via email to