From: Or Gerlitz <ogerlitz@mellanox.com>
To: Tom Herbert <therbert@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Jerry Chu <hkchu@google.com>,
"Eric Dumazet" <edumazet@google.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Linux Netdev List <netdev@vger.kernel.org>,
Yan Burman <yanb@mellanox.com>,
Shlomo Pongratz <shlomop@mellanox.com>
Subject: Re: [PATCH net-next V2 3/3] net: Add GRO support for vxlan traffic
Date: Wed, 8 Jan 2014 11:45:34 +0200 [thread overview]
Message-ID: <52CD1E3E.3090806@mellanox.com> (raw)
In-Reply-To: <CA+mtBx_Zctape7mAA=d-bvrFJbzn8f6tW5jBnPUcL5Cfhfai-g@mail.gmail.com>
On 07/01/2014 23:09, Tom Herbert wrote:
> On Tue, Jan 7, 2014 at 12:12 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
>> On Tue, Jan 7, 2014 at 10:02 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> On Tue, 2014-01-07 at 21:43 +0200, Or Gerlitz wrote:
>>>> On Tue, Jan 7, 2014 at 8:08 PM, Tom Herbert <therbert@google.com> wrote:
>>>>> Why ^ instead of != ?
>>>> The XOR approach is very popular in the GRO stack, e.g see the IPv4 chain
>>>> of inet_gro_receive() && tcp_gro_receive(), I guess this might relates
>>>> to more efficient assembly code for ^ vs. != and/or the fast/elegant
>>>> transitive nature of that operator
>>> This trick is only needed/used when many compares are folded into a
>>> single conditional :
>>>
>>> if (a->f1 != b->f1 || a->f2 != b->f2)
>>>
>>> ->
>>>
>>> if (((a->f1 ^ b->f1) | (a->f2 ^ b->f2)) != 0)
>>>
>>> Please do not use XOR for a single compare.
>> OK, but just out of curiosity -- what's the reasoning? clarity or
>> efficiency or both?
> Both. Compiling a simple program and comparing alternatives: gcc
> produced the identical code for the single conditional (^ vs !=)
> using the cmp instruction. Testing the two conditional case like Eric
> provided; the second method (using ^) resulted in 4 more instructions,
> but only one branch as opposed to two in the first method (!=). Method
> #1 has the advantage of short circuiting when the first condition is
> true, so organizing the conditionals to maximize the probability of
> short circuit could be beneficial.
OK, I will follow that.
Or.
next prev parent reply other threads:[~2014-01-08 9:46 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-07 15:29 [PATCH net-next V2 0/3] net: Add GRO support for UDP encapsulating protocols Or Gerlitz
2014-01-07 15:29 ` [PATCH net-next V2 1/3] " Or Gerlitz
2014-01-07 16:33 ` Eric Dumazet
2014-01-07 20:19 ` Or Gerlitz
2014-01-07 20:32 ` Eric Dumazet
2014-01-07 20:37 ` Or Gerlitz
2014-01-07 21:38 ` Eric Dumazet
2014-01-08 8:04 ` Or Gerlitz
[not found] ` <1389182291.26646.79.camel@edumazet-glaptop2.roam.corp.google.com>
2014-01-08 12:15 ` Or Gerlitz
2014-01-07 22:11 ` Jerry Chu
2014-01-08 8:02 ` Or Gerlitz
2014-01-09 3:12 ` Jerry Chu
2014-01-09 6:35 ` Or Gerlitz
2014-01-09 7:19 ` Or Gerlitz
2014-01-07 18:44 ` Tom Herbert
2014-01-07 20:21 ` Or Gerlitz
2014-01-07 23:04 ` Tom Herbert
2014-01-08 16:11 ` Or Gerlitz
2014-01-08 16:29 ` Tom Herbert
2014-01-08 16:31 ` Or Gerlitz
2014-01-07 21:19 ` David Miller
2014-01-07 21:40 ` Tom Herbert
2014-01-07 15:29 ` [PATCH net-next V2 2/3] net: Export gro_find_by_type helpers Or Gerlitz
2014-01-07 15:29 ` [PATCH net-next V2 3/3] net: Add GRO support for vxlan traffic Or Gerlitz
2014-01-07 16:34 ` Eric Dumazet
2014-01-07 19:43 ` Or Gerlitz
2014-01-07 20:04 ` Eric Dumazet
2014-01-07 20:10 ` Or Gerlitz
2014-01-07 18:08 ` Tom Herbert
2014-01-07 19:43 ` Or Gerlitz
2014-01-07 20:02 ` Eric Dumazet
2014-01-07 20:12 ` Or Gerlitz
2014-01-07 21:09 ` Tom Herbert
2014-01-08 9:45 ` Or Gerlitz [this message]
[not found] ` <CAJZOPZLsMvmHwmMjhsuKb__2HncMXMm=p6UFnT4XX5d8hZnGxw@mail.gmail.com>
2014-01-07 19:52 ` Tom Herbert
2014-01-07 16:45 ` [PATCH net-next V2 0/3] net: Add GRO support for UDP encapsulating protocols Eric Dumazet
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=52CD1E3E.3090806@mellanox.com \
--to=ogerlitz@mellanox.com \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=hkchu@google.com \
--cc=netdev@vger.kernel.org \
--cc=shlomop@mellanox.com \
--cc=therbert@google.com \
--cc=yanb@mellanox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.