From: Taku Izumi <izumi.taku@jp•fujitsu.com>
To: Jay Vosburgh <fubar@us•ibm.com>
Cc: Eric Dumazet <eric.dumazet@gmail•com>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
shemminger@vyatta•com
Subject: Re: [PATCH] bonding: add the sysfs interface to see RLB hash table
Date: Wed, 01 Dec 2010 14:09:21 +0900 [thread overview]
Message-ID: <4CF5D881.1090401@jp.fujitsu.com> (raw)
In-Reply-To: <12804.1291142278@death>
Dear Jay Volburgh and Stephen Hemminger:
(2010/12/01 3:37), Jay Vosburgh wrote:
> Eric Dumazet<eric.dumazet@gmail•com> wrote:
>
>> Le mardi 30 novembre 2010 à 19:01 +0900, Taku Izumi a écrit :
>>> This patch provides the sysfs interface to see RLB hash table
>>> like the following:
>>>
>>> # cat /sys/class/net/bond0/bonding/rlb_hash_table
>>>
>>> SourceIP DestinationIP Destination MAC DEV
>>> 10.124.196.205 10.124.196. 81 00:19:99:XX:XX:XX eth3
>>> 10.124.196.205 10.124.196.222 00:0a:79:XX:XX:XX eth0
>>> 10.124.196.205 10.124.196. 75 00:15:17:XX:XX:XX eth4
>>> 10.124.196.205 10.124.196. 1 00:21:d8:XX:XX:XX eth3
>>> 10.124.196.205 10.124.196.205 ff:ff:ff:ff:ff:ff eth0
>
> I'm reasonably sure something like this isn't going to be
> acceptable in sysfs (it's much too large).
>
> In the proc file that bonding already uses, this type of
> information isn't unreasonable, but I don't think that is the best place
> for this, for two reasons.
>
> First, the table may have up to 256 entries. Therefore, a
> sufficiently populated table will easily overrun the one page of space
> available to a sysfs show function or a proc seq_printf (per iteration),
> so it will have to handle that. The current code in bonding to do its
> proc file already iterates over the slaves; adding another iteration
> loop to handle this table seems overly complicated. A well populated
> table would also make the current proc file's output rather verbose,
> particularly if the TLB table is added later.
>
> Second, it would have to hold the hash table spin lock, which
> may provide an easy way to mess with bonding (user space doing "while 1
> cat rlb_hash_table> /dev/null").
>
> Therefore, I'd suggest this go into debugfs somewhere, perhaps a
> /sys/kernel/debug/bonding/rlb_hash_table (perhaps with a tlb_hash_table
> as the logical pairing for the TX side), readable only by root.
>
> Alternatively, if there are objections to using debufs, a new
> file in /proc/net/bonding could be used, although that seems cumbersome
> (because it would have to be named to avoid conflicts, e.g.,
> /proc/net/bonding/bond0_rlb_hash_table).
>
I understand the sysfs is not the proper place. I have no objection to using
debugfs. I'll try to rewrite my patch.
Taku Izumi <izumi.taku@jp•fujitsu.com>
next prev parent reply other threads:[~2010-12-01 5:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-30 10:01 [PATCH] bonding: add the sysfs interface to see RLB hash table Taku Izumi
2010-11-30 10:10 ` Eric Dumazet
2010-11-30 18:37 ` Jay Vosburgh
2010-12-01 5:09 ` Taku Izumi [this message]
2010-12-01 5:03 ` Taku Izumi
2010-11-30 22:08 ` Stephen Hemminger
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=4CF5D881.1090401@jp.fujitsu.com \
--to=izumi.taku@jp$(echo .)fujitsu.com \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=fubar@us$(echo .)ibm.com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shemminger@vyatta$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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