[RFC] IFLA_PORT_* iproute2 cmd line

[RFC] IFLA_PORT_* iproute2 cmd line

[Scott Feldman]

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?

-scott

Re: [RFC] IFLA_PORT_* iproute2 cmd line

[Arnd Bergmann]

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

Re: [RFC] IFLA_PORT_* iproute2 cmd line

[Scott Feldman]

On 5/26/10 5:38 AM, "Arnd Bergmann" <arnd@arndb.de> wrote:

> 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.

How does this strike you?

  Usage: ip link add link DEV [ name ] NAME
                     [ txqueuelen PACKETS ]
                     [ address LLADDR ]
                     [ broadcast LLADDR ]
                     [ mtu MTU ]
                     type TYPE [ ARGS ]
         ip link delete DEV type TYPE [ ARGS ]

         ip link set DEVICE [ { up | down } ]
                            [ arp { on | off } ]
                            [ dynamic { on | off } ]
                            [ multicast { on | off } ]
                            [ allmulticast { on | off } ]
                            [ promisc { on | off } ]
                            [ trailers { on | off } ]
                            [ txqueuelen PACKETS ]
                            [ name NEWNAME ]
                            [ address LLADDR ]
                            [ broadcast LLADDR ]
                            [ mtu MTU ]
                            [ netns PID ]
                            [ alias NAME ]
+                           [ virtualport MODE {PROFILE|VSI} ]
                            [ vf NUM [ mac LLADDR ]
                                     [ vlan VLANID [ qos VLAN-QOS ] ]
-                                    [ rate TXRATE ] ]
+                                    [ rate TXRATE ]
+                                    [ virtualport MODE {PROFILE|VSI} ] ]
         ip link show [ DEVICE ]

  TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | can }
+
+ MODE := { associate | preassociate | preassociaterr | disassociate }
+
+ 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 ]


> 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.

Let me get the user-to-kernel part working to establish the cmd line and you
can follow up with alternative addressing schemes.
 
> 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.

Re: [RFC] IFLA_PORT_* iproute2 cmd line

[Arnd Bergmann]

On Wednesday 26 May 2010, Scott Feldman wrote:
> On 5/26/10 5:38 AM, "Arnd Bergmann" <arnd@arndb.de> wrote:
> 
> How does this strike you?
> 
>   Usage: ip link add link DEV [ name ] NAME
>                      [ txqueuelen PACKETS ]
>                      [ address LLADDR ]
>                      [ broadcast LLADDR ]
>                      [ mtu MTU ]
>                      type TYPE [ ARGS ]
>          ip link delete DEV type TYPE [ ARGS ]
> 
>          ip link set DEVICE [ { up | down } ]
>                             [ arp { on | off } ]
>                             [ dynamic { on | off } ]
>                             [ multicast { on | off } ]
>                             [ allmulticast { on | off } ]
>                             [ promisc { on | off } ]
>                             [ trailers { on | off } ]
>                             [ txqueuelen PACKETS ]
>                             [ name NEWNAME ]
>                             [ address LLADDR ]
>                             [ broadcast LLADDR ]
>                             [ mtu MTU ]
>                             [ netns PID ]
>                             [ alias NAME ]
> +                           [ virtualport MODE {PROFILE|VSI} ]
>                             [ vf NUM [ mac LLADDR ]
>                                      [ vlan VLANID [ qos VLAN-QOS ] ]
> -                                    [ rate TXRATE ] ]
> +                                    [ rate TXRATE ]
> +                                    [ virtualport MODE {PROFILE|VSI} ] ]
>          ip link show [ DEVICE ]
> 
>   TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | can }
> +
> + MODE := { associate | preassociate | preassociaterr | disassociate }
> +
> + 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 ]

Right, exactly what I was thinking of. I would probably use
some shorter keywords (virtual-port -> port, port-profile -> profile,
instance-uuid -> instance, host-uuid -> host), but I really
don't have a strong opionion on that, so I'f fine with
whatever you and others come up with in that regard.

> > 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.
> 
> Let me get the user-to-kernel part working to establish the cmd line and you
> can follow up with alternative addressing schemes.

ok.

	Arnd

Re: [RFC] IFLA_PORT_* iproute2 cmd line

[Chris Wright]

* Stefan Berger (stefanb@us.ibm.com) wrote:
> When I have libvirt talk to my dummy server, I pass the getpid() of
> libvirt into the request message, just to fulfill the requirement of it
> being != 0 so the kernel driver doesn't process the msg. I also don't
> want to have to determine the pid of the target process. Now I believe
> the problem with that *may* be that multiple daemons may want to process
> the message,

What other daemon do you expect to be listening besides lldpad?

thanks,
-chris

Re: [RFC] IFLA_PORT_* iproute2 cmd line

[Arnd Bergmann]

On Wednesday 26 May 2010, Stefan Berger wrote:
> I can start my dummy netlink 'server' twice and have two recipients of the 
> libvirt 
> message and thus two servers can (maliciously) respond. Well, netlink 
> doesn't
> seem to be as 'directed' as unixio. We could run the netlink type of 
> messages

libvirt can still check if the sender pid of the response is what it
thinks it should be.

	Arnd