crossbow discuss - Dec 2006 - Some documentation/design nits for netrcm...

Looking at the man page for netrcm -

* the synopsis seems out of date with the examples and
  options presented;

* selection is possible on local address, local port and remote
  port.  Why not remote address as well?  Same for mac addr.

* I believe that it is worth stating somewhere what, if any,
  relationship the flow-id has with the flow label in IPv6,
  even though I expect it has none, but similar name...

* for local_mac_addr, wouldn''t it be easier to specify the
  vnic by name rather than ethernet address?  less fiddly
  digits to type.

Can I define a flow for a multicast/broadcast stream?

How would I use netrcm''s capabilities to deliver reliably
low latency for interactive traffic such as ssh?  Is this as
simple as doing:

netrcm add-flow -q transport=TCP,lport=22 -p high
netrcm add-flow -q transport=TCP,dport=22 -p high

Darren

Darren Reed wrote:
> Looking at the man page for netrcm -
>
> * the synopsis seems out of date with the examples and
>  options presented;
>
> * selection is possible on local address, local port and remote
>  port.  Why not remote address as well?  Same for mac addr.
>
> * I believe that it is worth stating somewhere what, if any,
>  relationship the flow-id has with the flow label in IPv6,
>  even though I expect it has none, but similar name...
No relationship.  And not related to Solaris IPQoS flows
either :).
> * for local_mac_addr, wouldn''t it be easier to specify the
>  vnic by name rather than ethernet address?  less fiddly
>  digits to type.
You can create a flow on a vnic.  Meem has pointed out
that we often use ''device'' or -d when we mean link.

#netrcm add-flow -d vnic3 transport=tcp tcp3
> Can I define a flow for a multicast/broadcast stream?
>
> How would I use netrcm''s capabilities to deliver reliably
> low latency for interactive traffic such as ssh?  Is this as
> simple as doing:
>
> netrcm add-flow -q transport=TCP,lport=22 -p high
> netrcm add-flow -q transport=TCP,dport=22 -p high
I''ve never heard of ''-q'' and you need to add the
device.

-Mike

Michael Lim(vpn) wrote:
> Darren Reed wrote:
>
>> Looking at the man page for netrcm -
>>
>> * the synopsis seems out of date with the examples and
>>  options presented;
>>
>> * selection is possible on local address, local port and remote
>>  port.  Why not remote address as well?  Same for mac addr.
>>
>> * I believe that it is worth stating somewhere what, if any,
>>  relationship the flow-id has with the flow label in IPv6,
>>  even though I expect it has none, but similar name...
>
>
> No relationship.  And not related to Solaris IPQoS flows
> either :).
>
>> * for local_mac_addr, wouldn''t it be easier to specify the
>>  vnic by name rather than ethernet address?  less fiddly
>>  digits to type.
>
>
> You can create a flow on a vnic.  Meem has pointed out
> that we often use ''device'' or -d when we mean link.
>
> #netrcm add-flow -d vnic3 transport=tcp tcp3

No, what I mean is to be able to say:

# netcrm add-flow local_mac_addr=vnic3,transport=tcp tcp3

or

# netrcm add-flow local_ip_addr=bge0 udp3

Defining a flow like this can be advantageous when using DHCP.

>> Can I define a flow for a multicast/broadcast stream?
>>
>> How would I use netrcm''s capabilities to deliver reliably
>> low latency for interactive traffic such as ssh?  Is this as
>> simple as doing:
>>
>> netrcm add-flow -q transport=TCP,lport=22 -p high
>> netrcm add-flow -q transport=TCP,dport=22 -p high
>
>
> I''ve never heard of ''-q'' and you need to add the
device.

ok, so:
netrcm add-flow -d bge0 -q transport=tcp,lport=22 -p high
netrcm add-flow -d bge0 -q transport=tcp,dport=22 -p high

The -q option is included in the examples on:

http://opensolaris.org/os/project/crossbow/pre-beta/manpagesdec2006/netrcm.1m.txt

but does not appear in the synponsis?

Darren

Darren Reed wrote On 12/14/06 17:22,:
>>
>>> * for local_mac_addr, wouldn''t it be easier to specify the
>>>  vnic by name rather than ethernet address?  less fiddly
>>>  digits to type.
>>
# dladm create-vnic -d bge0  -m random 1
will internally generate a random unicast MAC address to be vnic1''s 
ethernet addr.

and, for devices that come programmed multiple pre-defined MAC address 
values:
# dladm create-vnic -d xge0 -m factory 2
will slecect one of the predefined values and make it vnic2''s ethernet 
address.

The keyword ''factory'' and ''random'' are
planned for the Nevada release, and
will be pushed to the opensolaris snapshot when ready.
>>
>>
>> You can create a flow on a vnic.  Meem has pointed out
>> that we often use ''device'' or -d when we mean link.
>>
>> #netrcm add-flow -d vnic3 transport=tcp tcp3
>
>
>
> No, what I mean is to be able to say:
>
> # netcrm add-flow local_mac_addr=vnic3,transport=tcp tcp3
>
> or
>
> # netrcm add-flow local_ip_addr=bge0 udp3
>
> Defining a flow like this can be advantageous when using DHCP.
I''m not sure I understand what''s the desired behavior here.
It''s already possible to create a subflow of bge0 by
 # netrcm add-flow -d bge0 transport=udp udp3
whether bge0 is plumbed, up, or not.
If bge0 is plumbed and brought up, using DHCP, or user supplied IP address
*after* having called netrcm, then the new flow''s structure
(flow_entry_t)
previously created for udp3 gets stitched back to point to ip_input()
with the right ill_t (created by the plumbing step) and ill_ring.
See code path starting from dld_proto.c, proto_poll_enable()
calling dls_direct_rx_set()
The latter walks bge0''s flow table invoking dls_update_flow_client()
for
each of its sub-flows and does the right stitching.
>
>
>>> Can I define a flow for a multicast/broadcast stream?
>>>
>>> How would I use netrcm''s capabilities to deliver reliably
>>> low latency for interactive traffic such as ssh?  Is this as
>>> simple as doing:
>>>
>>> netrcm add-flow -q transport=TCP,lport=22 -p high
>>> netrcm add-flow -q transport=TCP,dport=22 -p high
>>
>>
>>
>> I''ve never heard of ''-q'' and you need to add
the device.
>
>
>
> ok, so:
> netrcm add-flow -d bge0 -q transport=tcp,lport=22 -p high
> netrcm add-flow -d bge0 -q transport=tcp,dport=22 -p high
>
> The -q option is included in the examples on:
>
>
http://opensolaris.org/os/project/crossbow/pre-beta/manpagesdec2006/netrcm.1m.txt
>
>
> but does not appear in the synponsis?

We have apologize for the volatility and sometimes inaccuracy  of our 
man pages.
The ''-q'' in the example will be fixed.
It is:
# netrcm add-flow -d <link name> transport=TCP local_port=22 
<flow_name>

To answer the question about latency, flow priority is the closest thing 
we can
use to help out, with the understanding that no guarantee of upper bound
on the response time.

    Kais.
>
> Darren
>
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss

http://opensolaris.org/os/project/crossbow/pre-beta/manpagesdec2006/netrcm.1m.txt

has been updated per Darren''s previous comments

    Kais.

Kais Belgaied wrote:
>
>
> Darren Reed wrote On 12/14/06 17:22,:
>
>>>
>>>> * for local_mac_addr, wouldn''t it be easier to specify
the
>>>>  vnic by name rather than ethernet address?  less fiddly
>>>>  digits to type.
>>>
>>>
>
> # dladm create-vnic -d bge0  -m random 1
> will internally generate a random unicast MAC address to be
vnic1''s
> ethernet addr.
>
> and, for devices that come programmed multiple pre-defined MAC address 
> values:
> # dladm create-vnic -d xge0 -m factory 2
> will slecect one of the predefined values and make it vnic2''s
ethernet
> address.
>
> The keyword ''factory'' and ''random'' are
planned for the Nevada release,
> and
> will be pushed to the opensolaris snapshot when ready.

Yes, but what I want to do use use the interface name
in the matching part of the dladm command line.
So...
>>> You can create a flow on a vnic.  Meem has pointed out
>>> that we often use ''device'' or -d when we mean
link.
>>>
>>> #netrcm add-flow -d vnic3 transport=tcp tcp3
>>
>>
>>
>>
>> No, what I mean is to be able to say:
>>
>> # netcrm add-flow local_mac_addr=vnic3,transport=tcp tcp3
>>
>> or
>>
>> # netrcm add-flow local_ip_addr=bge0 udp3
>>
>> Defining a flow like this can be advantageous when using DHCP.
>
>
> I''m not sure I understand what''s the desired behavior
here.
> It''s already possible to create a subflow of bge0 by
>  # netrcm add-flow -d bge0 transport=udp udp3
> whether bge0 is plumbed, up, or not.
> If bge0 is plumbed and brought up, using DHCP, or user supplied IP 
> address
> *after* having called netrcm, then the new flow''s structure 
> (flow_entry_t)
> previously created for udp3 gets stitched back to point to ip_input()
> with the right ill_t (created by the plumbing step) and ill_ring.
> See code path starting from dld_proto.c, proto_poll_enable()
> calling dls_direct_rx_set()
> The latter walks bge0''s flow table invoking
dls_update_flow_client() for
> each of its sub-flows and does the right stitching.

What I''m looking for here is the ability to use network interface
names in the address matching component of dladm''s command line.
So rather than be required to say "local_mac_addr=8:0:8:a:b:c", I can
write "local_mac_addr=nicX" where nicX owns mac address 8:0:8:a:b:c.
Same for IP address, rather than supply an actual address, I want
to supply an interface name instead.

I suppose a question here is, if there''s no need to be able to refer
to an address for use with local_mac_addr/local_ip_addr by interface
name then why are these needed at all?

I suppose what I''m getting at is being able to do:

dladm add-flow -d bge1 local_ip_addres=bge0,transport=udp udp3

do define a new flow of UDP packets coming in bge1 to an address
that is a property of bge0.

Darren

> * for local_mac_addr, wouldn''t it be easier to specify the
 >  vnic by name rather than ethernet address?  less fiddly
 >  digits to type.

 You can create a flow on a vnic.  Meem has pointed out
 that we often use ''device'' or -d when we mean link.

So we can do a flow above any of

	device, aggregation, vnic

and does it help to mention vlan as well ?

-r

...and while I think of it, anywhere that we have a MAC address,
it would be nice to be able to use a name that comes from /etc/ethers
or the ethers NIS map (see ether_hostton()).

Darren

valid suggestion.
CR# 6506152 was filed to track this.

Thanks,

    Kais.

Darren Reed wrote On 12/18/06 10:43 PM,:
> ...and while I think of it, anywhere that we have a MAC address,
> it would be nice to be able to use a name that comes from /etc/ethers
> or the ethers NIS map (see ether_hostton()).
>
> Darren
>