public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
To: "Upinder Malhi (umalhi)"
	<umalhi-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
Cc: "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"<roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Dreier"
	<roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH for-next] IB/usnic: Expose flows via debugfs
Date: Sun, 12 Jan 2014 11:32:55 +0200	[thread overview]
Message-ID: <52D26147.4010709@mellanox.com> (raw)
In-Reply-To: <BDC9DBAD-3303-4A61-85C6-4F49957E693E-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>

On 08/01/2014 20:57, Upinder Malhi (umalhi) wrote:
> Or,
> 	Yeah, I did think about extending the existing infrastructure to export HW specific stats and exposing some stats via standard infrastructure.  Besides the below, there are few other drawbacks with exposing statistics via netlink:
> 1) Having a two part solution, users space and kernel, will make changing the code more difficult.  Anytime another attributed is exposed, code in the kernel needs to be added to handle backwards compatibility with userspace (as I said we are going to add more stuff incrementally).

There are thousands if not millions LOCs over the kernel and user space 
tools which use netlink. Indeed when you have two for tango you 
sometimes change one side, sometimes the other and sometimes both.  A 
claim that "its easier to maintain  things when all the code resides in 
the kernel" can't be really taken seriously into account.  Netlink is 
used all over the place, so everyone's wrong?



> 2)  The Cisco VIC series cards, that is our NIC, cannot do flow stats well.  Specially, it only reports Rx byte count for a flow and doesn't report any statistics on the Tx side.  Hence, exposing these via  a standard interface to a user is going to be confusing and misleading.

1st use the standard/existing interface to report the open sessions and 
later we'll take it from there re the byte counts.


>
> Hence, at least for Cisco VIC, we want to keep these flow stats in debugfs where they can be easily extended and extra effort is required to get to them.
>
> Upinder
>
> On Jan 8, 2014, at 1:13 AM, Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
>
>> On 08/01/2014 00:29, Upinder Malhi (umalhi) wrote:
>>> Or, The flows contain Cisco VIC specific stuff - Ex. the hardware flow id; and they will contain more cisco specific things.  Hence, they are exported via debugfs.
>> You should be able to enhance the rdma netlink infrastructure to allow for exporting HW dependent attributes to user space -- did you look on that?
>>
>> Also, you should make sure to expose the non HW specific attributes of the sessions through the standard infrastructure.
>>
>> Or.
>>
>>
>>
>>
>>> Upinder
>>>
>>> On Dec 22, 2013, at 2:23 AM, Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
>>>
>>>> On 20/12/2013 23:37, Upinder Malhi (umalhi) wrote:
>>>>> This patch depends onhttp://www.spinics.net/lists/linux-rdma/msg18193.html
>>>> Why use proprietary debugfs code  to display flows? you can (and should) use the rdma subsystem netlink infrastructure for that, see these
>>>> two commits
>>>>
>>>>
>>>> 753f618 RDMA/cma: Add support for netlink statistics export
>>>> b2cbae2 RDMA: Add netlink infrastructure
>>>>
>>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2014-01-12  9:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-20 21:37 [PATCH for-next] IB/usnic: Expose flows via debugfs Upinder Malhi (umalhi)
     [not found] ` <6F4F8D2C-F10F-4697-ABD5-552D2E696361-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2013-12-22 10:23   ` Or Gerlitz
     [not found]     ` <52B6BDAF.6030407-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2014-01-07 22:29       ` Upinder Malhi (umalhi)
     [not found]         ` <BC780FB0-731D-42FA-B003-E61B473B23E2-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2014-01-08  9:13           ` Or Gerlitz
     [not found]             ` <52CD16CE.7080804-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2014-01-08 18:57               ` Upinder Malhi (umalhi)
     [not found]                 ` <BDC9DBAD-3303-4A61-85C6-4F49957E693E-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2014-01-12  9:32                   ` Or Gerlitz [this message]
     [not found]                     ` <52D26147.4010709-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2014-01-13 22:14                       ` Upinder Malhi (umalhi)
     [not found]                         ` <9D597492-61CB-4C2D-9853-87EEFEA64BEA-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2014-01-13 23:39                           ` Or Gerlitz
     [not found]                             ` <CAJZOPZK9K+kxZ5NuBtir30uOwVciSEVtpxJX6HxZ+xhi9M7whA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-01-14  0:13                               ` Upinder Malhi (umalhi)

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=52D26147.4010709@mellanox.com \
    --to=ogerlitz-vpraknaxozvwk0htik3j/w@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=umalhi-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.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