From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CE95C282C0 for ; Fri, 25 Jan 2019 13:53:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CAC3920881 for ; Fri, 25 Jan 2019 13:53:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KrVHucYk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728238AbfAYNxA (ORCPT ); Fri, 25 Jan 2019 08:53:00 -0500 Received: from mail-ed1-f68.google.com ([209.85.208.68]:42697 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726347AbfAYNxA (ORCPT ); Fri, 25 Jan 2019 08:53:00 -0500 Received: by mail-ed1-f68.google.com with SMTP id y20so7422737edw.9 for ; Fri, 25 Jan 2019 05:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WR4ACHWW89Or0FoA1Rn+JWRwpNIrvVd+TzeSerbJ1gM=; b=KrVHucYk40ulqTRVD5fyRKqfNiK/Ink3uDjknmwguOAhgaofSDPGbchyqls++CI+hI ECV84j+CNRotgCCMDFpDxxqMgTev/mpRAUv3/h6FRppGlFq4l/BVlhPTBPIK3NO4a/Kl cwV8jT0RkmT7JK44bOQlkwYSAF97AnbEfwkvfXXnubjit8F/B+qtsIrRZBUbSz4dEPa/ tNTBwUSJMG4KwZzipKNcVuQ3isEdd8xB6X8dVjlHHClaZ45Q2WehePV3VcnAtmbEaCph AWXz6/I/JW4jGPrawHj+P1H1tznwksR1y8uxC3KnDJmKRPyNGjVWZnnultvXQpPtZrAb D0RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WR4ACHWW89Or0FoA1Rn+JWRwpNIrvVd+TzeSerbJ1gM=; b=nWdM2SG4t8zJyw0mB7ejS+jIeqhNGCNlq1A+S/4mKPyl9Po1FAO+NxCEECE7qAU/PQ xCV+U85DXRT+R7MjPlWqv7jWKb+aYRw3M0PsvKT5Ks9Ffxd+5lZsD26uKy2VYal2gxzx 47oehvB257OtBj5KtTlipcOG0lwZefYH6QIFDp5gRRfR1rvc2wSTELXZL62QG6YX8AWr 5/qB4U0HAVSvrUSDgQz4wFah9pHlhsa2fdt7mlJA7eWjqPRLCVAOsOYkoOqKp8A73dx0 W8W5djWB+LIvPk6o5/PaYUXMSfXxU8TL0y4Q7IByKsQSeMo+u5NH6X3CkyaDwikJpzWP Kj2g== X-Gm-Message-State: AJcUukeJyAX3CshBczHIrnJEJ+yt804ZmBEkL0MUrdfCaEJEXnaxSlHR 84HdjfLk5SIAQsYteHGNORp3tf2SdgbFAs4J9A8= X-Google-Smtp-Source: ALg8bN4spJ7FQPBpNNCEWPUS/D/ev74j4RfVNmW0vRdpZT9Q0Jauruu9vl5Lllj1CCwl8FAnDu7q17vtY1deqIdTkoA= X-Received: by 2002:aa7:dace:: with SMTP id x14mr11223714eds.13.1548424378600; Fri, 25 Jan 2019 05:52:58 -0800 (PST) MIME-Version: 1.0 References: <20190114131841.1932-1-maximmi@mellanox.com> <20190114131841.1932-4-maximmi@mellanox.com> In-Reply-To: From: Willem de Bruijn Date: Fri, 25 Jan 2019 08:52:21 -0500 Message-ID: Subject: Re: [PATCH 3/7] net/ethernet: Add parse_protocol header_ops support To: Maxim Mikityanskiy Cc: "David S. Miller" , Saeed Mahameed , Willem de Bruijn , Jason Wang , Eric Dumazet , "netdev@vger.kernel.org" , Eran Ben Elisha , Tariq Toukan Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > > > > > diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h > > > > > index 2c0af7b00715..e2f3b21cd72a 100644 > > > > > --- a/include/linux/etherdevice.h > > > > > +++ b/include/linux/etherdevice.h > > > > > @@ -44,6 +44,7 @@ int eth_header_cache(const struct neighbour *neigh, > > > > struct hh_cache *hh, > > > > > __be16 type); > > > > > void eth_header_cache_update(struct hh_cache *hh, const struct > > net_device > > > > *dev, > > > > > const unsigned char *haddr); > > > > > +__be16 eth_header_parse_protocol(const struct sk_buff *skb); > > > > > > > > Does not need to be exposed in the header file or exported. > > > > > > Are you sure? All the other Ethernet header_ops callbacks are exported > > > and declared in the header. I'm not sure about the reason why it is done > > > in such a way, but my guess is that it will be useful if some driver > > > decides to replace one callback in header_ops but to use the default > > > ones for the rest of callbacks. > > > > I don't exactly follow this. But I think that many are exported > > because Ethernet is so common that of these are also called directly > > instead of through header_ops. Looking at other header_ops > > implementations, or other such callback structs, shows many examples > > where the members are static local functions. > > Yes, they are called directly indeed, but not all of them. E.g., > eth_header_parse is never called directly. On the other hand, look at > drivers/net/macvlan.c: > > static const struct header_ops macvlan_hard_header_ops = { > .create = macvlan_hard_header, > .parse = eth_header_parse, > .cache = eth_header_cache, > .cache_update = eth_header_cache_update, > }; > > This is exactly what I am talking about. In order to support it, > eth_header_parse_protocol needs to be exported. BTW, we should consider > adding it to macvlan_hard_header_ops, ipvlan_header_ops and all other > such structures. Very good point. Okay, export it is then.