[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM6PR05MB5879042EACDF22EC71830577D19B0@AM6PR05MB5879.eurprd05.prod.outlook.com>
Date: Fri, 25 Jan 2019 08:51:12 +0000
From: Maxim Mikityanskiy <maximmi@...lanox.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
CC: "David S. Miller" <davem@...emloft.net>,
Saeed Mahameed <saeedm@...lanox.com>,
Willem de Bruijn <willemb@...gle.com>,
Jason Wang <jasowang@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Eran Ben Elisha <eranbe@...lanox.com>,
Tariq Toukan <tariqt@...lanox.com>
Subject: RE: [PATCH 3/7] net/ethernet: Add parse_protocol header_ops support
> -----Original Message-----
> From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
> Sent: 24 January, 2019 16:22
> To: Maxim Mikityanskiy <maximmi@...lanox.com>
> Cc: David S. Miller <davem@...emloft.net>; Saeed Mahameed
> <saeedm@...lanox.com>; Willem de Bruijn <willemb@...gle.com>; Jason Wang
> <jasowang@...hat.com>; Eric Dumazet <edumazet@...gle.com>;
> netdev@...r.kernel.org; Eran Ben Elisha <eranbe@...lanox.com>; Tariq Toukan
> <tariqt@...lanox.com>
> Subject: Re: [PATCH 3/7] net/ethernet: Add parse_protocol header_ops support
>
> On Thu, Jan 24, 2019 at 4:48 AM Maxim Mikityanskiy <maximmi@...lanox.com>
> wrote:
> >
> > > -----Original Message-----
> > > From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
> > > Sent: 23 January, 2019 16:15
> > > To: Maxim Mikityanskiy <maximmi@...lanox.com>
> > > Cc: David S. Miller <davem@...emloft.net>; Saeed Mahameed
> > > <saeedm@...lanox.com>; Willem de Bruijn <willemb@...gle.com>; Jason Wang
> > > <jasowang@...hat.com>; Eric Dumazet <edumazet@...gle.com>;
> > > netdev@...r.kernel.org; Eran Ben Elisha <eranbe@...lanox.com>; Tariq
> Toukan
> > > <tariqt@...lanox.com>
> > > Subject: Re: [PATCH 3/7] net/ethernet: Add parse_protocol header_ops
> support
> > >
> > > On Mon, Jan 14, 2019 at 8:21 AM Maxim Mikityanskiy
> <maximmi@...lanox.com>
> > > wrote:
> > > >
> > > > The previous commit introduced parse_protocol callback which should
> > > > extract the protocol number from the L2 header. Make all Ethernet
> > > > devices support it.
> > > >
> > > > Signed-off-by: Maxim Mikityanskiy <maximmi@...lanox.com>
> > > > ---
> > > > include/linux/etherdevice.h | 1 +
> > > > net/ethernet/eth.c | 13 +++++++++++++
> > > > 2 files changed, 14 insertions(+)
> > > >
> > > > 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.
Powered by blists - more mailing lists