netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Thery <benjamin.thery@bull.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Daniel Lezcano <dlezcano@fr.ibm.com>,
	Linux Containers <containers@lists.osdl.org>,
	netdev@vger.kernel.org
Subject: Re: L2 network namespace benchmarking (resend with Service Demand)
Date: Fri, 06 Apr 2007 13:19:36 +0200	[thread overview]
Message-ID: <46162CC8.7080708@bull.net> (raw)
In-Reply-To: <m1d52i9bfg.fsf@ebiederm.dsl.xmission.com>

Eric W. Biederman wrote:
> Daniel Lezcano <dlezcano@fr.ibm.com> writes:
> 
>> Hi,
>>
>> as suggested Rick, I added the Service Demand results to the matrix.
> 
> A couple of random thoughts in trying to understand the numbers you are
> seeing.
> 
> - Checksum offloading?
> 
>   You have noted that with the bridge netfilter support disabled you
>   are still seeing additional checksum overhead.  Just like you are
>   seeing in the routing case.
> 
>   Is it possible the problem is simply that etun doesn't support
>   checksum offloading, while your normal test hardware does?

Looks like you are 100% correct.
I feel a bit stupid I didn't think about this "small" difference 
between real NIC and etun.

If I turn off checksum offloading on my physical NIC, the checksum 
"overhead" (load) measured by oprofile is about the same in both case: 
when running netperf through a real NIC or through an etun tunnel first.

Benjamin

> - Tagged VLANs?
>   
>   Currently you have tested bridging and routing to get the packets to
>   a network namespace.  Could you test tagged vlans?
> 
>   I'm just curious if we have anything in the network stack today that
>   will multiplex a NIC without measurable overhead.
> 
> - Without NETNS?
> 
>   We should probably see if we can setup the same configuration we are
>   testing without network namespaces (just multiple interfaces on the
>   same machine) and see if we can still measure the same overhead.
>   Just to confirm the overhead is not a network namespace related
>   thing.
> 
>   I know we can configure the same case with bridging and I am fairly
>   confident that we will see the same overhead without network
>   namespaces.
> 
>   Of the top of my head I am insufficiently clever to think how we
>   could configure the routing case without network namespaces,
>   although we might be able to force it and if so it would be
>   interesting to measure.
> 
> I will work to get the etun setup races fixed and to fix whatever
> obvious feature deficiencies it has (like no configurable MTU support)
> and see if I can get that pushed upstream.  That should make it easier
> for other people to reproduce what we are seeing.
> 
> Eric
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
> 


-- 
B e n j a m i n   T h e r y  - BULL/DT/Open Software R&D

    http://www.bull.com

  reply	other threads:[~2007-04-06 11:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-30 14:16 L2 network namespace benchmarking (resend with Service Demand) Daniel Lezcano
2007-03-30 15:30 ` Eric W. Biederman
2007-04-06  8:03 ` Eric W. Biederman
2007-04-06 11:19   ` Benjamin Thery [this message]
2007-04-06 14:25     ` Eric W. Biederman

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=46162CC8.7080708@bull.net \
    --to=benjamin.thery@bull.net \
    --cc=containers@lists.osdl.org \
    --cc=dlezcano@fr.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).