Subject: Re: [RFC] IFLA_PORT_* iproute2 cmd line

From: Arnd Bergmann <[email-masked]>
Date: Wed, 26 May 2010 14:38:06 +0200

On Wednesday 26 May 2010, Scott Feldman wrote:
> I need to provide an iproute2 patch for IFLA_PORT_* and I wanted to hash out
> the cmd line before I submit it.  Here's what I think would work based on
> previous input from Arnd:
> 
> Usage:  ip port associate DEVICE [ vf NUM ] {PROFILE|VSI}
>         ip port pre-associate DEVICE [ vf NUM ] VSI
>         ip port pre-associate-rr DEVICE [ vf NUM ] VSI
>         ip port dis-associate DEVICE [ vf NUM ]
>         ip port show [ DEVICE [ vf NUM ] ]
> 
>         PROFILE := port-profile PORT-PROFILE
>                    [ instance-uuid INSTANCE-UUID ]
>                    [ host-uuid HOST-UUID ]
> 
>         VSI := vsi managerid MGR typeid VTID typeidversion VER
>                [ instance-uuid INSTANCE-UUID ]
> 
> Comments?

The syntax of the PROFILE and VSI arguments seems ok, but I'm
not sure where exactly to put them.

When talking to the kernel, I think this should be part of 
link command, because that is the underlying protocol:

ip link set DEVICE [vf NUM] {associate {PROFILE|VSI}    |
			     pre-associate-rr VSI       |
			     pre-associate VSI          |
			     disassociate }
ip link show [ DEVICE [ vf NUM ] ] 

This will also let you combine the association with additional
"vf mac" and "vf vlan" commands as needed.

The more interesting question is how to do this when we
talk to lldpad. One idea was to use the same protocol
but to direct the message to a specific pid (that of lldpad).
That would require adding an option like '-p PID' to ip
that lets us change who we talk to.

Alternatively, we could also create a top-level command like
the one you described, but just use it for the case when
we're talking to lldpad, finding out the PID from the
/var/run/lldpdad.pid internally. Right now, I'm leaning
towards the more flexible option of being able to direct
the command anywhere.

	Arnd