[crossbow-discuss] mystery surrounding mac_set_mtu()

I looked at the code, both in current onnv, and in onnv_110. The call to mac_mark_exclusive() seems pretty redundant since mac_open() will itself block on the i_mac_perim_enter as Seb initially pointed out. so I agree with Seb's removal of that particular line.. --Sowmini

[crossbow-discuss] mystery surrounding mac_set_mtu()

On (08/14/09 18:23), Thirumalai Srinivasan wrote: >> > The perimeter does ensure that only 1 thread can do mac_set_mtu() at a > time on the given mac. But I am not sure why mac_set_mtu() wants to > call mac_mark_exclusive(). Is it that not all drivers implement the > mac_maxsdu_update()

[crossbow-discuss] property parsing in dladm

On (04/10/09 13:37), Sunay Tripathi wrote: > > Not sure what ifconfig got to do with virtualization? In most the frequently heard complaint about ifconfig is that, as a CLI, it is overloaded and tries to do too many things in one command line. > virtual machine cases the vnics are never plumbed.

[crossbow-discuss] property parsing in dladm

On (04/10/09 13:17), Sunay Tripathi wrote: > > How many commands should one run to be able to create a VNIC with > some link speed and CPU assignments necessary to configure a virtual > machine? Keep in mind that people do run thousands of zones > on one machine. This was a very strong feedback fro

[crossbow-discuss] property parsing in dladm

On (04/10/09 13:10), Michael Lim wrote: >> >> 6601421 dladm set-linkprop should support multiple -p options >> > I probably fixed this with my putback for > 6796069 dladm > set-linkprop for multiple props succeeds even if some values are invalid

[crossbow-discuss] property parsing in dladm

On (04/10/09 13:04), venugopal iyer wrote: >> Is there an inherent neeed to support this rather than just having the >> admin do a set-linkprop afterwards? > > I suppose from an admin's point, it does provide a way to create a link > with certain props directly, rather than following dladm create-

[crossbow-discuss] property parsing in dladm

On (04/10/09 12:20), venugopal iyer wrote: > > We support bandwidth/cpu etc. properties for vlans (via dladm create-vlan - > just like a vlan created by dladm create-vnic -v) and aggrs. Ok, that needs to be documented appropriately. another major RFE in this area is for libdladm to use nvlists.

[crossbow-discuss] property parsing in dladm

I decided to take a stab at 6601421 dladm set-linkprop should support multiple -p options along with some related linkprop fixes, but when I looked into dladm.c, was surprised to find that "dladm_parse_props()" is called from do_create_aggr and do_create_vlan in addition to the expected (by me

[crossbow-discuss] [networking-discuss] dlstat for data link statistics

On (03/23/09 14:25), Peter Memishian wrote: > > Agreed. Ideally, ofmt would automatically determine how best to format > based on the available screen width (which it knows). but this leads to a certain amount of unpredictability in the output. As long as that constraint is acceptable ofmt has t

[crossbow-discuss] [networking-discuss] dlstat for data link statistics

On (03/17/09 11:21), Peter Memishian wrote: > > > If I might make a suggestion of an alternative to this: > > > > Put in the man page for the command the -o string that can be used to > > reproduce the default output (and when options change that default > > output, give an equivalent -o str

[crossbow-discuss] [networking-discuss] dlstat for data link statistics

On (03/16/09 21:34), Peter Memishian wrote: > > >* It's not clear to me why we need both "kstat mode" and "full-screen" > > > mode. If we do need to keep both, I'd be inclined to use "-k" for > > > kstat mode rather than "-v". > > Am fine with -k as well (Changed in the man page)

[crossbow-discuss] Finishing up the contributors list as well

On (02/16/09 14:46), Sunay Tripathi wrote: > > > Current contributors list: > > yun,Zhou Yun,20,networking,Networking,2009-02-24 00:32:45 > sommerfe,Bill Sommerfeld,20,networking,Networking,2009-02-24 00:32:45 > pwernau,Paul Werna

[crossbow-discuss] Need to renew core contributors or will loose community status

> Sowmini Varadhan - Brussels and IP Routing/Forwarding I accept my nomination (with votes from Thirumalai Srinivasan, Jim Carlson, Peter Memishian). --Sowmini ~ ~

[crossbow-discuss] Crossbow Code Review Phase II ready

On (09/08/08 15:05), Kais Belgaied wrote: > > The webrev is available in > http://www.opensolaris.org/os/project/crossbow/Code-review2 : > Interested? please send the code review comments by September 20th, 2008 Sorry this is a little late, and I only looked at specific parts of this quickly, bu

[crossbow-discuss] [brussels-dev] [networking-discuss] code review Brussels persistence

On (06/04/08 17:52), Cathy Zhou wrote: > I thought wifi link properties will also be initialized in the same code path? > > dls_prop_load()->dls_mgmt_linkprop_init()-> > dlmgmt_upcall_linkprop_init()->dladm_init_linkprop() > that's true, I'd forgotten about that. > Like I said, some o

[crossbow-discuss] [brussels-dev] [networking-discuss] code review Brussels persistence

> d. Do we still need special handling for wifi devices in network-physical? > Also, is it possible for "dladm init-linkprop" to take one specific name > (which requires the changes in the do_init_linkprop() function)? Artem can confirm, but we'll need this as long as the wifi drivers are not co

[crossbow-discuss] [brussels-dev] code review Brussels persistence

On (06/02/08 14:25), Artem Kachitchkine wrote: > One important thing I forgot to mention. The in-kernel property cache is > technically no longer need: we always propagate properties from the > ioctl straight into mc_setprop. I see two reasons to retain the cache: > > - Observability/diagnostics

[crossbow-discuss] [brussels-dev] code review Brussels persistence

On (04/22/08 11:48), Artem Kachitchkine wrote: >> - Don't we still need lines 209-218 for wifi drivers? > > Good question. If we have any kind of persistence for wifi drivers, it > seems to be working by accident. That is, it relies on drivers not being > unloaded, and the system is free to d

[crossbow-discuss] [brussels-dev] code review Brussels persistence

Artem, Looks good overall! here's my feedback (if a file's not listed, I have no specific comments on it). --Sowmini --- usr/src/cmd/svc/milestone/net-physical - Don't we still need lines 209-218 for wifi drivers? usr/sr

[networking-discuss] Re: [crossbow-discuss] webrev: conversion of dmfe to nemo

On (04/18/07 08:30), Garrett D'Amore wrote: > Oliver Yang wrote: > >Garrett D'Amore wrote: > >> > >> > >>Another wrinkle is that of course only a few drivers support the > >>netlb.h ioctls, since they were never formally published anywhere. > >>This is another tunable that I'd like brussels to j

[crossbow-discuss] Code review for IP Instances

> > > - ip_ftable.h line 64 and ip_ire.c line 2877: please clarify the > > "no netstack_hold()" comment? seems like the ipst is obtained from > >the ill_ipst or conn_netstack->netstack_ip, or by marching down some > > global netstack list, so what does the comment refer to? > > It refer

[crossbow-discuss] Code review for IP Instances

Erik, Yukun, Dong-Hai, I haven't reviewed all the files, but focussed on the surya-related pieces. Here's what I came up with: files reviewed: ip_ndp.[ch], ip_ire.[ch], ip_ftable.[ch], netstack.c, ip_if.c, ip.c - ip_ndp.h: need to remove the foollowing two decls (Comments hav