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
next prev parent 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).