[ovs-dev] one genetlink family vs. many (was: Re: [netlink v4 27/52] datapath: Change userspace vport interface...)
blp at nicira.com
Thu Jan 20 00:00:00 UTC 2011
On Mon, Jan 17, 2011 at 03:21:45PM -0800, Jesse Gross wrote:
> On Mon, Jan 17, 2011 at 1:47 PM, Ben Pfaff <blp at nicira.com> wrote:
> >> The rationale for putting fields in the header vs attributes is not
> >> very clear to me (with the obvious exception of the length fields).
> >> It's perhaps not such a big deal here because we do need the fixed
> >> header at the beginning to hold the lengths. ?However, in the later
> >> patches where we actually use Netlink, this seems to lead unnecessary
> >> complexity. ?Having these fields in the header means that different
> >> operations have different headers, which means that we have different
> >> families. ?The end result is that we have a proliferation of families
> >> and structs. ?I would expect it to have one family with maybe a fixed
> >> header consisting of just the DP index.
> > The difference between approaches is a matter of philosophy. ?I had
> > viewed each of the four families (datapath, vport, flow, upcall) as a
> > separate entity and thus given each of them a separate header and
> > family. ?But I can see that using a single family with a shared header
> > or perhaps no header at all would simplify other matters, as you say.
> > There is no technical reason we cannot do it the way you suggest. ?It
> > had not occurred to me before to do it that way. ?If you prefer this
> > approach, then I will rework things to work that way instead.
> I guess I would prefer to make things a single family - I have a hard
> time logically justifying having so many different families and it
> seems that other parts of the kernel generally only have one.
> Combining them would shrink the interface, which is a pretty big win
> to me.
I came in today intending to work on this, but I haven't had much luck
coming up with a coherent format to deal with all of these disparate
entities in a single Netlink family. Usually I start in on something
like that by looking at what all or most of the families have in common,
putting that in a common area, and then breaking the rest into separate
parts. But these families don't have a lot in common. The only
property that they all have is a datapath (if)index, and there are only
a couple of attributes shared by more than one.
Do you have something in mind? Would you mind sketching it out?
I'm not sure that it's really true that other parts of the kernel
generally have only one. Looking through the RTM_* constants in
RTM_*LINK has struct ifinfomsg and IFLA_* attributes.
RTM_*ADDR has struct ifaddrmsg and IFA_* attributes.
RTM_*ROUTE has struct rtmsg and RTA_* attributes.
RTM_*NEIGH has struct ndmsg and NDA_* attributes.
RTM_*RULE has struct fib_rule_hdr and FRA_* attributes.
RTM_*QDISC, RTM_*TCLASS, and RTM_*FILTER share struct tcmsg and
the TCA_* attributes.
RTM_*ACTION has struct tcamsg and TCAA_* attributes.
Based on the precedents I could go either way (as long as we can come up
with a reasonable single-family formulation).
More information about the dev