* [RFC] IFLA_PORT_* iproute2 cmd line
@ 2010-05-26 3:19 Scott Feldman
2010-05-26 12:38 ` Arnd Bergmann
0 siblings, 1 reply; 6+ messages in thread
From: Scott Feldman @ 2010-05-26 3:19 UTC (permalink / raw)
To: netdev; +Cc: Chris Wright, Stephen Hemminger, Arnd Bergmann
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] IFLA_PORT_* iproute2 cmd line
2010-05-26 3:19 [RFC] IFLA_PORT_* iproute2 cmd line Scott Feldman
@ 2010-05-26 12:38 ` Arnd Bergmann
2010-05-26 14:49 ` Scott Feldman
[not found] ` <OFCF88A167.122DD206-ON8525772F.00470999-8525772F.0047F4A5@us.ibm.com>
0 siblings, 2 replies; 6+ messages in thread
From: Arnd Bergmann @ 2010-05-26 12:38 UTC (permalink / raw)
To: Scott Feldman
Cc: netdev, Chris Wright, Stephen Hemminger, Stefan Berger,
Dirk Herrendoerfer, Vivek Kashyap
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] IFLA_PORT_* iproute2 cmd line
2010-05-26 12:38 ` Arnd Bergmann
@ 2010-05-26 14:49 ` Scott Feldman
2010-05-27 7:00 ` Arnd Bergmann
[not found] ` <OFCF88A167.122DD206-ON8525772F.00470999-8525772F.0047F4A5@us.ibm.com>
1 sibling, 1 reply; 6+ messages in thread
From: Scott Feldman @ 2010-05-26 14:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: netdev, Chris Wright, Stephen Hemminger, Stefan Berger,
Dirk Herrendoerfer, Vivek Kashyap
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] IFLA_PORT_* iproute2 cmd line
[not found] ` <OFCF88A167.122DD206-ON8525772F.00470999-8525772F.0047F4A5@us.ibm.com>
@ 2010-05-26 15:56 ` Chris Wright
[not found] ` <OFB3363EDA.945755DA-ON8525772F.0057CBD1-8525772F.00589D2B@us.ibm.com>
0 siblings, 1 reply; 6+ messages in thread
From: Chris Wright @ 2010-05-26 15:56 UTC (permalink / raw)
To: Stefan Berger
Cc: Arnd Bergmann, Chris Wright, Dirk Herrendoerfer, netdev,
Scott Feldman, Stephen Hemminger, Vivek Kashyap
* 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] IFLA_PORT_* iproute2 cmd line
[not found] ` <OFB3363EDA.945755DA-ON8525772F.0057CBD1-8525772F.00589D2B@us.ibm.com>
@ 2010-05-26 16:15 ` Arnd Bergmann
0 siblings, 0 replies; 6+ messages in thread
From: Arnd Bergmann @ 2010-05-26 16:15 UTC (permalink / raw)
To: Stefan Berger
Cc: Chris Wright, Dirk Herrendoerfer, netdev, Scott Feldman,
Stephen Hemminger, Vivek Kashyap
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] IFLA_PORT_* iproute2 cmd line
2010-05-26 14:49 ` Scott Feldman
@ 2010-05-27 7:00 ` Arnd Bergmann
0 siblings, 0 replies; 6+ messages in thread
From: Arnd Bergmann @ 2010-05-27 7:00 UTC (permalink / raw)
To: Scott Feldman
Cc: netdev, Chris Wright, Stephen Hemminger, Stefan Berger,
Dirk Herrendoerfer, Vivek Kashyap
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-05-27 7:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-26 3:19 [RFC] IFLA_PORT_* iproute2 cmd line Scott Feldman
2010-05-26 12:38 ` Arnd Bergmann
2010-05-26 14:49 ` Scott Feldman
2010-05-27 7:00 ` Arnd Bergmann
[not found] ` <OFCF88A167.122DD206-ON8525772F.00470999-8525772F.0047F4A5@us.ibm.com>
2010-05-26 15:56 ` Chris Wright
[not found] ` <OFB3363EDA.945755DA-ON8525772F.0057CBD1-8525772F.00589D2B@us.ibm.com>
2010-05-26 16:15 ` Arnd Bergmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).