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