netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Stephane Bryant <stephane.ml.bryant@gmail.com>,
	netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next 3/3] netfilter: bridge: copy back VLAN header for bridge packet queued to userspace
Date: Fri, 15 Jan 2016 15:04:12 +0100	[thread overview]
Message-ID: <20160115140412.GD7462@breakpoint.cc> (raw)
In-Reply-To: <20160115110218.GA2361@salvia>

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> For the specific case of nfnetlink_queue, I would expose the vlan
> information through a new netlink attribute NFQA_VLAN (similar to what
> we do for NFQA_HWADDR for the layer 3).

If we do this I think it does make sense to consider putting
the entire L2 mac header under its own attr too.

This is especially good if we'd later add support for NETDEV
family.  Since drivers already pull the L2 header userspace
would not need to handle arbirary L2 protocols.

> > +				payload += VLAN_HLEN;
> > +				payload_len -= VLAN_HLEN;
> > +			} else {
> > +				entry->skb->vlan_tci &= ~VLAN_TAG_PRESENT;
> > +				entry->skb->protocol = veth->h_vlan_proto;
> > +			}
> > +		}
> 
> I'm awar it's more work, but it would be good to reduce ifdef pollution
> by placing all this bridge netfilter code wrapped into functions under
> one single ifdef in this file to improve maintainability.

Right, but for anything family specifiy it would be even better to push
it into nf afinfo. In case thats too much work or too cumbersome (e.g.
because you'd need 12 function arguments ...) then the ifdef-wrapped
helper is fine of course.

  reply	other threads:[~2016-01-15 14:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15  8:48 [PATCH nf-next 0/3] netfilter: bridge: add queuing to userspace for AF_BRIDGE family Stephane Bryant
2016-01-15  8:48 ` [PATCH nf-next 1/3] netfilter: bridge: add nf_afinfo to enable queuing to userspace Stephane Bryant
2016-01-15  9:06   ` kbuild test robot
2016-01-15  9:49   ` Florian Westphal
2016-01-20 14:34     ` stéphane bryant
2016-01-20 15:52       ` Florian Westphal
2016-01-15  8:48 ` [PATCH nf-next 2/3] netfilter: bridge: pull back mac header into skb queued " Stephane Bryant
2016-01-15  8:48 ` [PATCH nf-next 3/3] netfilter: bridge: copy back VLAN header for bridge packet " Stephane Bryant
2016-01-15 10:06   ` Florian Westphal
2016-01-15 10:49     ` Florian Westphal
2016-01-15 11:02   ` Pablo Neira Ayuso
2016-01-15 14:04     ` Florian Westphal [this message]
2016-01-15 16:33       ` Pablo Neira Ayuso
2016-01-16 11:00         ` stéphane bryant
2016-01-16 11:06           ` Florian Westphal
2016-01-23  9:30       ` stéphane bryant
2016-01-23 20:39         ` Florian Westphal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160115140412.GD7462@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=stephane.ml.bryant@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).