[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADxym3YHMOe8VfO0sPr8rPOBL+KhT2_DBoby5HUkBDNDOZCtYw@mail.gmail.com>
Date: Tue, 15 Oct 2024 09:55:39 +0800
From: Menglong Dong <menglong8.dong@...il.com>
To: Ido Schimmel <idosch@...dia.com>
Cc: kuba@...nel.org, aleksander.lobakin@...el.com, horms@...nel.org,
davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
dsahern@...nel.org, dongml2@...natelecom.cn, amcohen@...dia.com,
gnault@...hat.com, bpoirier@...dia.com, b.galvani@...il.com,
razor@...ckwall.org, petrm@...dia.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH net-next v7 08/12] net: vxlan: use kfree_skb_reason() in vxlan_xmit()
On Mon, Oct 14, 2024 at 11:47 PM Ido Schimmel <idosch@...dia.com> wrote:
>
> On Mon, Oct 14, 2024 at 08:35:57PM +0800, Menglong Dong wrote:
> > On Sun, Oct 13, 2024 at 8:43 PM Ido Schimmel <idosch@...dia.com> wrote:
> > >
> > > On Wed, Oct 09, 2024 at 10:28:26AM +0800, Menglong Dong wrote:
> > > > Replace kfree_skb() with kfree_skb_reason() in vxlan_xmit(). Following
> > > > new skb drop reasons are introduced for vxlan:
> > > >
> > > > /* no remote found for xmit */
> > > > SKB_DROP_REASON_VXLAN_NO_REMOTE
> > > > /* packet without necessary metadata reached a device which is
> > > > * in "external" mode
> > > > */
> > > > SKB_DROP_REASON_TUNNEL_TXINFO
> > > >
> > > > Signed-off-by: Menglong Dong <dongml2@...natelecom.cn>
> > > > Reviewed-by: Simon Horman <horms@...nel.org>
> > >
> > > Reviewed-by: Ido Schimmel <idosch@...dia.com>
> > >
> > > The first reason might be useful for the bridge driver as well when
> > > there are no ports to forward the packet to (because of egress filtering
> > > for example), but we can make it more generic if / when the bridge
> > > driver is annotated.
> >
> > You are right. As we already need a new version, so we can
> > do something for this patch too. As you said, maybe we can rename the
> > reason VXLAN_NO_REMOTE to NO_REMOTE for more generic
> > usage?
>
> "NO_REMOTE" is not really applicable to the bridge driver as there are
> no remotes, but bridge ports. I'm fine with keeping it as is for now and
> changing it later if / when needed.
Okay!
Powered by blists - more mailing lists