Hi, Sorry for the delayed reply, This API points to the default mac address associated with pktio port. This is useful incase if the application wants to know the mac address of the interface in which it wants to send the packet out. Incase if the port supports multiple mac address that can be handled an API added to the classifier.
Regards, Bala On 14 October 2014 18:40, Gilad Ben Yossef <gil...@ezchip.com> wrote: > > The assumption that a pkt_io has a MAC address and a single one at that is > pretty weird. > Sure, on board LAN and PCIe NIC cards or USB dongles have an eeprom with a > factory MAC address - but your L2 switch doesn't have a MAC address per > port and even many NICs support several MAC address to filter on (for > example for multicast) > When I use this API - what is it am I asking? Which MAC was burned by the > silicon vendor for this pkt_io, if it even has any? Which MAC is used right > now to filter incoming frames by this pkt_io? These might not be the same > due to multicast, promiscuous mode etc. > In a sense it seems to be more related to the Classifier API than pkt_io > API. > > Gilad Ben-Yossef > Software Architect > EZchip Technologies Ltd. > 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel > Tel: +972-4-959-6666 ext. 576, Fax: +972-8-681-1483 > Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 > Email: gil...@ezchip.com, Web: http://www.ezchip.com > > "Ethernet always wins." > — Andy Bechtolsheim > > > > -----Original Message----- > > From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp- > > boun...@lists.linaro.org] On Behalf Of Ciprian Barbu > > Sent: Tuesday, October 14, 2014 3:32 PM > > To: Bala Manoharan > > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp@lists.linaro.org > > Subject: Re: [lng-odp] [ODP/PATCH v6] API support for querying mac > > address > > > > On Mon, Oct 13, 2014 at 3:21 PM, Bala Manoharan > > <bala.manoha...@linaro.org> wrote: > > > Hi, > > > > > > ODP_MAX_MACADDR_SIZE was needed since we wanted this API to be > > compliant for > > > both 6 and 8 byte MAC address. > > > Since we are having odp_pktio_t as abstract application cannot assume > > the > > > mac address to be the size of Ethernet. > > > That was the whole point behind having an MAX size being defined by the > > > platform and returning the size as an output parameter. > > > > It doesn't feel right to me to have a platform dependent > > MAX_MACADDR_SIZE. Sure it could be the size of the longest MAC address > > of the interfaces that exist on the board in question, but you still > > have USB ports that could be used to connect a whole range of devices, > > firewire like Ola mentioned and who knows what else. To limit > > ourselves to Ethernet devices is a safe bet, but can't we do more? I > > would suggest something similar to Petri's idea, pass the destination > > buffer and it's size and the API to return the number of bytes copied > > if that was enough, or the number of bytes necessary otherwise. > > Something like snprintf, but not assuming we're copying a readable > > string. > > > > > > > > My proposal is to keep the mechanism to support any size of MAC address > > but > > > only implement the same for Ethernet in the ODP v1.0 so that there is > > no > > > change in the API signature when updating for v2.0 > > > > > > Regards, > > > Bala > > > > > > > > > On 10 October 2014 19:41, Bill Fischofer <bill.fischo...@linaro.org> > > wrote: > > >> > > >> I agree. The only protocols we're dealing with in ODP v1.0 are > > Ethernet > > >> and for that MACs follow the EUI-48 format so they are always 6 bytes > > in > > >> length. > > >> > > >> Bill > > >> > > >> On Fri, Oct 10, 2014 at 4:11 AM, Savolainen, Petri (NSN - FI/Espoo) > > >> <petri.savolai...@nsn.com> wrote: > > >>> > > >>> I think ODP_MAX_MACADDR_SIZE is not needed in API, if user gives > > >>> sizeof(mac_addr) and func returns size copied. It can be added in > > eth > > >>> helper file though (e.g. ODPH_ETH_MACADDR_SIZE_MAX). > > >>> > > >>> > > >>> > > >>> It’s again a protocol definition that I’d rather leave out when > > possible. > > >>> > > >>> > > >>> > > >>> -Petri > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> From: lng-odp-boun...@lists.linaro.org > > >>> [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext Bala > > Manoharan > > >>> Sent: Friday, October 10, 2014 10:00 AM > > >>> To: Maxim Uvarov > > >>> Cc: lng-odp@lists.linaro.org > > >>> Subject: Re: [lng-odp] [ODP/PATCH v6] API support for querying mac > > >>> address > > >>> > > >>> > > >>> > > >>> Hi, > > >>> > > >>> > > >>> > > >>> * I will change the ODP_MAX_MACADDR_SIZE as 8. where should this > > macro be > > >>> defined is it okay to have it in the current odp_packet_io.h header > > file. > > >>> > > >>> * I will change the name of the api from odp_pktio_get_mac_addr() to > > >>> odp_pktio_mac_addr() > > >>> > > >>> * I will incorporate anders comments also. > > >>> > > >>> Any other changes required for this patch? > > >>> > > >>> Regards, > > >>> > > >>> Bala > > >>> > > >>> > > >>> > > >>> On 9 October 2014 21:12, Maxim Uvarov <maxim.uva...@linaro.org> > > wrote: > > >>> > > >>> On 10/09/2014 02:24 PM, Ola Liljedahl wrote: > > >>> > > >>> Some interface types use 64-bit MAC addresses (e.g. Firewire). > > >>> > > >>> I think the ODP API should specify a recommended buffer size (e.g. > > >>> #define ODP_MACADDR_SIZE 8) and then return the actual length of the > > return > > >>> MAC address. > > >>> The application passes a buffer and a buffer size (this could be 6 if > > the > > >>> application is sure that the interface uses a MAC48 address). If the > > buffer > > >>> size is too small for the actual MAC address, an error is returned > > (e.g. > > >>> -1). > > >>> > > >>> -- Ola > > >>> > > >>> > > >>> ETH_ALEN is 6. So looks like patch needed to be update. > > >>> > > >>> Maxim. > > >>> > > >>> > > >>> On 8 October 2014 19:08, Maxim Uvarov <maxim.uva...@linaro.org > > >>> <mailto:maxim.uva...@linaro.org>> wrote: > > >>> > > >>> On 10/07/2014 11:47 AM, Bala Manoharan wrote: > > >>> > > >>> > > >>> > > >>> On 7 October 2014 12:43, Savolainen, Petri (NSN - FI/Espoo) > > >>> <petri.savolai...@nsn.com <mailto:petri.savolai...@nsn.com> > > >>> <mailto:petri.savolai...@nsn.com > > >>> <mailto:petri.savolai...@nsn.com>>> wrote: > > >>> > > >>> > > >>> > > >>> > -----Original Message----- > > >>> > From: 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>> [mailto:lng-odp- > > >>> <mailto:lng-odp-> > > >>> <mailto:lng-odp- <mailto:lng-odp->> > > >>> > boun...@lists.linaro.org > > >>> <mailto:boun...@lists.linaro.org> > > >>> <mailto:boun...@lists.linaro.org > > >>> <mailto:boun...@lists.linaro.org>>] On > > >>> Behalf Of ext Balasubramanian Manoharan > > >>> > Sent: Monday, October 06, 2014 7:16 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>> > > >>> > Subject: [lng-odp] [ODP/PATCH v6] API support for > > >>> querying mac > > >>> address > > >>> > > > >>> > This patch contains API support for querying mac > > address > > >>> using > > >>> odp_pktio_t > > >>> > handle > > >>> > This patch incorporates the latest ODP_ERR and > > ODP_ABORT > > >>> changes > > >>> done in > > >>> > linux-generic repo > > >>> > > > >>> > Signed-off-by: Balasubramanian Manoharan > > >>> <bala.manoha...@linaro.org > > >>> <mailto:bala.manoha...@linaro.org> > > >>> <mailto:bala.manoha...@linaro.org > > >>> > > >>> > > >>> <mailto:bala.manoha...@linaro.org>>> > > >>> > --- > > >>> > example/ipsec/odp_ipsec.c | 9 ++++++-- > > >>> > platform/linux-generic/include/api/odp_packet_io.h | 17 > > >>> +++++++++++++++ > > >>> > platform/linux-generic/odp_packet_io.c | 24 > > >>> > ++++++++++++++++++++++ > > >>> > platform/linux-generic/odp_packet_socket.c | 16 > > >>> ++++++++++----- > > >>> > 4 files changed, 59 insertions(+), 7 deletions(-) > > >>> > > > >>> > diff --git a/example/ipsec/odp_ipsec.c > > >>> b/example/ipsec/odp_ipsec.c > > >>> > index ec6c87a..9a46a0c 100644 > > >>> > --- a/example/ipsec/odp_ipsec.c > > >>> > +++ b/example/ipsec/odp_ipsec.c > > >>> > @@ -549,7 +549,8 @@ void initialize_intf(char *intf) > > >>> > char inq_name[ODP_QUEUE_NAME_LEN]; > > >>> > odp_queue_param_t qparam; > > >>> > int ret; > > >>> > - uint8_t src_mac[ODPH_ETHADDR_LEN]; > > >>> > + uint8_t src_mac[ODP_MAC_ADDR_MAX_LENGTH]; > > >>> > > >>> I think a helper definition should be used here. I'd not > > >>> include > > >>> protocol definitions/types into the main ODP API. > > >>> > > >>> I wanted a design to help the platform decide the maximum > > size > > >>> of MAC_ADDR supported. Any approach is fine. > > >>> > > >>> > > >>> > > >>> > + size_t mac_addr_size; > > >>> > char src_mac_str[MAX_STRING]; > > >>> > > > >>> > /* > > >>> > @@ -587,8 +588,12 @@ void initialize_intf(char *intf) > > >>> > /* Read the source MAC address for this interface > > */ > > >>> > #if USE_MAC_ADDR_HACK > > >>> > ret = query_mac_address(intf, src_mac); > > >>> > + (void)mac_addr_size; > > >>> > #else > > >>> > - ret = odp_pktio_get_mac_addr(pktio, src_mac); > > >>> > + ret = odp_pktio_get_mac_addr(pktio, src_mac, > > >>> &mac_addr_size); > > >>> > + if (mac_addr_size != ODPH_ETHADDR_LEN) { > > >>> > + ODP_ABORT("Ethernet mac address length > > not > > >>> supported"); > > >>> > + } > > >>> > #endif > > >>> > if (ret) { > > >>> > ODP_ERR("Error: failed during MAC address > > >>> get for > > >>> %s\n", > > >>> > intf); > > >>> > diff --git > > >>> a/platform/linux-generic/include/api/odp_packet_io.h > > >>> > b/platform/linux-generic/include/api/odp_packet_io.h > > >>> > index 29fd105..2086316 100644 > > >>> > --- a/platform/linux- > > generic/include/api/odp_packet_io.h > > >>> > +++ b/platform/linux- > > generic/include/api/odp_packet_io.h > > >>> > @@ -125,6 +125,23 @@ void > > >>> odp_pktio_set_input(odp_packet_t pkt, > > >>> > odp_pktio_t id); > > >>> > */ > > >>> > odp_pktio_t odp_pktio_get_input(odp_packet_t pkt); > > >>> > > > >>> > +/** > > >>> > + * Defines the maximum length of mac address supported > > >>> by this > > >>> platform > > >>> > + */ > > >>> > +#define ODP_MAC_ADDR_MAX_LENGTH ETH_ALEN > > >>> > + > > >>> > +/** > > >>> > + * Get mac address of the interface > > >>> > + * > > >>> > + * @param id ODP packet IO handle > > >>> > + * @param mac_addr Storage for Mac address of the > > >>> packet IO > > >>> interface > > >>> > + * Storage provided by the caller > > >>> should be equal > > >>> > + * to ODP_MAC_ADDR_MAX_LENGTH > > (filled by > > >>> function) > > >>> > > >>> "filled by function" ==> output parameter > > >>> > > >>> > + * @param addr_size Size of the Mac address (filled > > by > > >>> function) > > >>> > > >>> I think it would be more logical if this is input > > >>> parameter (== > > >>> sizeof(mac_addr)) and used for error checking. Function > > could > > >>> return the number of bytes copied (6 or 8) on success > > (and > > >>> 0 on > > >>> failure). User should know beforehand how large MAC > > address > > >>> to > > >>> expect, right? > > >>> > > >>> I believe having the maximum MAC_ADDR length being defined by > > >>> the platform makes the application agnostic across different > > >>> platform implementations and different types of odp_pktio_t > > >>> instances. > > >>> Having the size being returned as a parameter seemed to be > > >>> more inline with current ODP API design. > > >>> > > >>> > > >>> Can mac addr be different size? I saw only 6 bytes macs. Not sure > > >>> if it can be different size. And if it can not be than we don't > > >>> need ODP_MAC_ADDR_MAX_LENGTH. > > >>> > > >>> Maxim. > > >>> > > >>> > + * @return 0 on success or -1 on error > > >>> > +**/ > > >>> > +int odp_pktio_get_mac_addr(odp_pktio_t id, unsigned > > >>> char *mac_addr, > > >>> > + size_t *addr_size); > > >>> > > >>> To be inline with other accessor functions "get" should > > be > > >>> dropped. What if an interface is configured to accept > > >>> multiple mac > > >>> addresses? Is this the default address (every interface > > >>> should > > >>> have at least one mac address). How other MACs are > > >>> inquired? Or is > > >>> it part of classification then. > > >>> > > >>> This API would return the default MAC addr of the instance. > > >>> Returning multiple mac addr which was assigned to a specific > > >>> interface could be done by classification. > > >>> > > >>> Regards, > > >>> Bala > > >>> > > >>> > > >>> > > >>> -Petri > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> lng-odp mailing list > > >>> > > >>> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> > > >>> http://lists.linaro.org/mailman/listinfo/lng-odp > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> lng-odp mailing list > > >>> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> > > >>> http://lists.linaro.org/mailman/listinfo/lng-odp > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> lng-odp mailing list > > >>> lng-odp@lists.linaro.org > > >>> http://lists.linaro.org/mailman/listinfo/lng-odp > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> lng-odp mailing list > > >>> lng-odp@lists.linaro.org > > >>> http://lists.linaro.org/mailman/listinfo/lng-odp > > >>> > > >> > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
