public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Antonio Quartulli <ordex@autistici.org>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: access h_vlan_encapsulated_proto properly
Date: Sun, 12 May 2013 10:42:20 +0200	[thread overview]
Message-ID: <20130512084220.GH901@ritirata.org> (raw)
In-Reply-To: <20130512082448.GG901@ritirata.org>

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

On Sun, May 12, 2013 at 03:25:10PM +0800, Marek Lindner wrote:
> > On Tuesday, May 07, 2013 19:54:02 Antonio Quartulli wrote:
> > > In the gateway code in case of VLAN tagged frame the ethhdr
> > > pointer is moved forward by 4 bytes so that the offset of
> > > h_proto in struct ethhdr matches the real
> > > h_vlan_encapsulated_proto address in the skb.
> > > 
> > > This trick is correct but the code is not easy to understand
> > > and may lead to bugs in case of re-use of ethhdr for other
> > > purposes.
> > > 
> > > Use a standalone protocol variable and assign it accordingly
> > > to the header type
> > 
> > How about adding the key word "refactoring" somewhere into the subject line or 
> > the commit message ?
> 


oky


> 
> > 
> > 
> > > @@ -626,23 +626,29 @@ bool batadv_gw_is_dhcp_target(struct sk_buff *skb,
> > > unsigned int *header_len) struct iphdr *iphdr;
> > >  	struct ipv6hdr *ipv6hdr;
> > >  	struct udphdr *udphdr;
> > > +	uint16_t proto;
> > > 
> > >  	/* check for ethernet header */
> > >  	if (!pskb_may_pull(skb, *header_len + ETH_HLEN))
> > >  		return false;
> > >  	ethhdr = (struct ethhdr *)skb->data;
> > > +	proto = ntohs(ethhdr->h_proto);
> > >  	*header_len += ETH_HLEN;
> > > 
> > >  	/* check for initial vlan header */
> > > -	if (ntohs(ethhdr->h_proto) == ETH_P_8021Q) {
> > > +	if (proto == ETH_P_8021Q) {
> > > +		struct vlan_ethhdr *vhdr;
> > > +
> > 
> > While we are refactoring I suggest to not ntohs() the protocol every time but 
> > the protocol constants. The compiler will replace the constants with the 
> > appropriate number during the compilation, thus saving us from a runtime 
> > operation every time we check a packet.
> > 
> 

oh right. I did not think about it. I guess I have to use __constant_htons
instead of the plain hntons.

cheers,


 -- 
 Antonio Quartulli

 ..each of us alone is worth nothing..
 Ernesto "Che" Guevara



-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      parent reply	other threads:[~2013-05-12  8:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-07 11:54 [B.A.T.M.A.N.] [PATCH] batman-adv: access h_vlan_encapsulated_proto properly Antonio Quartulli
2013-05-12  7:25 ` Marek Lindner
     [not found]   ` <20130512082448.GG901@ritirata.org>
2013-05-12  8:42     ` Antonio Quartulli [this message]

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=20130512084220.GH901@ritirata.org \
    --to=ordex@autistici.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /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