> EAGAIN translates to the perror "No more processes" in errno.h :-(
>
> whereas EBUSY is more in line with the update_drv error, which is
> the closest parallel.
There's no rule that we have to use perror() to print error messages -- or
that we need to restrict diagnostics to errno values.
James Carlson wrote:
[EMAIL PROTECTED] writes:
We could fail the operation, but the question of finding the right
error code to be returned by the SETPROP ioctl remains: attempts
to modunload a used module seem to return EBUSY- we could return that
back to dladm and then have dladm react appr
[EMAIL PROTECTED] wrote:
On (06/26/07 01:06), Peter Memishian wrote:
> situation, it is the driver's responsibility to emit a log message
> saying when the change will be effective (e.g., the next stop/start
> pair). The dladm/gldv3 framework itself would not interfere with the
> behavior
On (06/26/07 09:20), Garrett D'Amore wrote:
>> What we could do is to have a distinct error code to
>> track this case (EINTR?) that could be caught by dladm to emit the
>> information to the user- would that suffice?
>>
>
> EAGAIN would be a better choice.
>
EAGAIN translates to the perror "N
[EMAIL PROTECTED] writes:
> We could fail the operation, but the question of finding the right
> error code to be returned by the SETPROP ioctl remains: attempts
> to modunload a used module seem to return EBUSY- we could return that
> back to dladm and then have dladm react appropriately.
Sure; i
On (06/26/07 10:01), James Carlson wrote:
>
> [EMAIL PROTECTED] writes:
> > On (06/26/07 01:06), Peter Memishian wrote:
> > > While I can understand that from an implementation standpoint, from a
> > > usability standpoint I don't think a log message goes far enough. The
> > > person running the
[EMAIL PROTECTED] writes:
> On (06/26/07 01:06), Peter Memishian wrote:
> > While I can understand that from an implementation standpoint, from a
> > usability standpoint I don't think a log message goes far enough. The
> > person running the dladm set-linkprop subcommand needs the feedback.
>
>
On (06/26/07 01:06), Peter Memishian wrote:
> > situation, it is the driver's responsibility to emit a log message
> > saying when the change will be effective (e.g., the next stop/start
> > pair). The dladm/gldv3 framework itself would not interfere with the
> > behavior.
>
> While I can unde
> > Okay. While I understand what you've written at the top of page 10, there
> > are still questions in my mind. How does the software know whether or not
> > a given property is currently in effect, or won't be in effect until
> > something else is done at a later time? How will the ad
Andrew Gallatin wrote:
Garrett D'Amore writes:
> The problem here is that the only reason to lower the MTU is to deal
> with cases where Path MTU discovery fails. For example, lowering the
> MTU because your upstream provider doesn't properly deal with frames
> larger than a PPP size or some
Jeremy Harris wrote:
An alternative for this specific case would surely be a more intelligent
implementation of pmtuD. RFC4821 exists; has anyone looked into doing
an implementation?
One drawback to this method is that it depends on an existing transport
protocol which is able to quickly dete
Garrett D'Amore wrote:
Sebastien Roy wrote:
Garrett D'Amore wrote:
Lowering the MTU is done at the IP layer.
That's a bug IMO. IP should just use the MTU reported by the layer
underneath. Any modification of MTU needs to be done from the bottom
of the stack, not the top.
The problem her
Andrew Gallatin wrote:
Garrett D'Amore writes:
> Andrew Gallatin wrote:
> > Garrett D'Amore writes:
> > > Andrew Gallatin wrote:
> > > > Garrett D'Amore writes:
> > > > > The problem here is that the only reason to lower the MTU is to deal
> > > > > with cases where Path MTU discover
On (06/25/07 12:23), Sebastien Roy wrote:
> Okay. While I understand what you've written at the top of page 10, there
> are still questions in my mind. How does the software know whether or not
> a given property is currently in effect, or won't be in effect until
> something else is done at a
Garrett D'Amore writes:
> Andrew Gallatin wrote:
> > Garrett D'Amore writes:
> > > Andrew Gallatin wrote:
> > > > Garrett D'Amore writes:
> > > > > The problem here is that the only reason to lower the MTU is to
> > deal
> > > > > with cases where Path MTU discovery fails. For exam
Andrew Gallatin wrote:
Garrett D'Amore writes:
> Andrew Gallatin wrote:
> > Garrett D'Amore writes:
> > > The problem here is that the only reason to lower the MTU is to deal
> > > with cases where Path MTU discovery fails. For example, lowering the
> > > MTU because your upstream prov
Garrett D'Amore writes:
> Andrew Gallatin wrote:
> > Garrett D'Amore writes:
> > > The problem here is that the only reason to lower the MTU is to deal
> > > with cases where Path MTU discovery fails. For example, lowering the
> > > MTU because your upstream provider doesn't properly de
Raymond LI - Sun Microsystems - Beijing China wrote:
Michael Speer wrote:
All,
This is an excellent document. Please look the configuration paremeters
for nxge (Neptune and N2 NIU) for parameters that should be considered.
Michael,
To support 10G, we will need to add "adv-10gfdx-cap", "adv-1
Andrew Gallatin wrote:
Garrett D'Amore writes:
> The problem here is that the only reason to lower the MTU is to deal
> with cases where Path MTU discovery fails. For example, lowering the
> MTU because your upstream provider doesn't properly deal with frames
> larger than a PPP size or s
[EMAIL PROTECTED] wrote:
On (06/24/07 20:14), Sebastien Roy wrote:
I don't see it. Maybe I'm not looking hard enough. I'm looking for a
discussion detailing the implications of setting properties when there are
active DLS clients utilizing a link. Is it okay to set all kinds of
properties a
On (06/24/07 20:14), Sebastien Roy wrote:
>>> Section 3:
>>>
>>> * Some details are needed regarding when it is valid to set a property's
>>> value. We've had discussions before about potential problem with
>>> modifying some properties after a driver has attached. Have these issues
>>> been w
Garrett D'Amore writes:
> The problem here is that the only reason to lower the MTU is to deal
> with cases where Path MTU discovery fails. For example, lowering the
> MTU because your upstream provider doesn't properly deal with frames
> larger than a PPP size or somesuch.
>
> Its frus
Michael Speer wrote:
All,
This is an excellent document. Please look the configuration paremeters
for nxge (Neptune and N2 NIU) for parameters that should be considered.
Michael,
To support 10G, we will need to add "adv-10gfdx-cap", "adv-10ghdx-cap"
in the doc, to be public properties. Other
[EMAIL PROTECTED] wrote:
* The description of "Well-known" property is very confusing to me. How
can such properties (you list link speed and auto-neg as examples) be
expected to occur in every driver if the properties are only inherent to
specific media types? Also, how can they be expected
Sebastien Roy wrote:
Garrett D'Amore wrote:
For the mtu case: the MTU definitiion targetted in the doc was intended
to address the driver's default_mtu (the tunable typically tweaked
by setting various params in the driver.conf to get Jumbo Frames).
As you point out, there is a related concept
Garrett D'Amore wrote:
For the mtu case: the MTU definitiion targetted in the doc was intended
to address the driver's default_mtu (the tunable typically tweaked
by setting various params in the driver.conf to get Jumbo Frames). As
you point out, there is a related concept of the GLDv3 max SDU w
[EMAIL PROTECTED] wrote:
On (06/23/07 11:17), Sebastien Roy wrote:
http://opensolaris.org/os/project/brussels/files/brussels.pdf
thanks very much for the review!
General:
* It would be good to note in the document title that this is a design
document.
done (will show
On (06/23/07 11:17), Sebastien Roy wrote:
> > http://opensolaris.org/os/project/brussels/files/brussels.pdf
thanks very much for the review!
> General:
>
> * It would be good to note in the document title that this is a design
> document.
done (will show up in next rev)
> Section 2.1:
>
>
All,
This is an excellent document. Please look the configuration paremeters
for nxge (Neptune and N2 NIU) for parameters that should be considered.
Michael
Sebastien Roy wrote:
[EMAIL PROTECTED] wrote:
http://opensolaris.org/os/project/brussels/files/brussels.pdf
Excellent document. M
[EMAIL PROTECTED] wrote:
http://opensolaris.org/os/project/brussels/files/brussels.pdf
Excellent document. My comments are based on version 0.2.
General:
* It would be good to note in the document title that this is a design
document.
Section 2.1:
* The description of "Well-known" pr
> > > document the driver's private properties correctly after Brussel?
> >
> > Minimally, in the driver's manpage.
>
> Well, documenting private properties is something that needs to be
> done with extreme discretion, becuase private properties are an extremely
> Unstable interface. Ho
[EMAIL PROTECTED] wrote:
On (06/22/07 10:26), Garrett D'Amore wrote:
Why not have mac_prop_lookup go to the DDI properties on behalf of the
driver? (In other words, instead of going up to some daemon, if the daemon
isn't present, just use the driver.conf properties.)
What I'm getting at i
On (06/22/07 10:26), Garrett D'Amore wrote:
>
> Why not have mac_prop_lookup go to the DDI properties on behalf of the
> driver? (In other words, instead of going up to some daemon, if the daemon
> isn't present, just use the driver.conf properties.)
>
> What I'm getting at is, this detail, can
On (06/22/07 08:37), Garrett D'Amore wrote:
>
> The upshot of this, is that I think it makes sense to consider the
> following approach. Please let me know your thoughts:
>
>Consider a brussels strategy of "importing" initial values from DDI
>properties. (I.e. look first there for initi
[EMAIL PROTECTED] wrote:
On (06/22/07 08:37), Garrett D'Amore wrote:
The upshot of this, is that I think it makes sense to consider the
following approach. Please let me know your thoughts:
Consider a brussels strategy of "importing" initial values from DDI
properties. (I.e. look f
[EMAIL PROTECTED] wrote:
On (06/20/07 11:21), Erik Nordmark wrote:
Brussels properties will be available when the driver attaches: early on
in the xxx_attach routine, each converted driver will invoke dladmd with a
door_upcall and persistent properties will be loaded up in the kernel
for th
On (06/20/07 11:21), Erik Nordmark wrote:
>
>> Brussels properties will be available when the driver attaches: early on
>> in the xxx_attach routine, each converted driver will invoke dladmd with a
>> door_upcall and persistent properties will be loaded up in the kernel
>> for the driver as part
[EMAIL PROTECTED] wrote:
On (06/20/07 11:21), Erik Nordmark wrote:
[EMAIL PROTECTED] wrote:
Brussels properties will be available when the driver attaches: early on
in the xxx_attach routine, each converted driver will invoke dladmd with a
door_upcall and persistent properties will be loa
On (06/20/07 11:21), Erik Nordmark wrote:
> [EMAIL PROTECTED] wrote:
>
>> Brussels properties will be available when the driver attaches: early on
>> in the xxx_attach routine, each converted driver will invoke dladmd with a
>> door_upcall and persistent properties will be loaded up in the kerne
Raymond LI - Sun Microsystems - Beijing China wrote:
Garrett D'Amore wrote:
* i'd like to see more public tunables. E.g. the lance_mode, ipg0,
ipg1, ipg2 values exposed by all NSN drivers.
I wonder if we could add more public properties in 2nd phase's
scope. In the first stage, it focuses on
Garrett D'Amore wrote:
* i'd like to see more public tunables. E.g. the lance_mode, ipg0,
ipg1, ipg2 values exposed by all NSN drivers.
I wonder if we could add more public properties in 2nd phase's scope.
In the first stage, it focuses on bge/e1000g/nge, which don't have
those tunables supp
[EMAIL PROTECTED] wrote:
Brussels properties will be available when the driver attaches: early on
in the xxx_attach routine, each converted driver will invoke dladmd with
a door_upcall and persistent properties will be loaded up in the kernel
for the driver as part of the door_upcall. So this
On (06/20/07 10:39), Erik Nordmark wrote:
>
>> However, given that driver.conf is used for non-network driver parameters
>> as well, I don't think driver.conf itself can be completely eradicated
>> even if it is somewhat clumsy to use. Brussels will, at least, provide
>> a cleaner method for netwo
[EMAIL PROTECTED] wrote:
I'm not very familiar with diskless boot, so could you please you help
me understand the typical usage here? It seems to me
that if a diskless client tries to change configuration permanently
at runtime, the settings would be attached to config files in the server,
so th
On (06/19/07 00:36), Peter Memishian wrote:
>
> > I have a question when reviewing our design doc today. How do we
> > document the driver's private properties correctly after Brussel?
>
> Minimally, in the driver's manpage.
>
Well, documenting private properties is something that needs to b
Garrett D'Amore wrote:
"link_cksum_offload" controls tx/rx checksum enabling as well.
Framework seems not having this as tunable so far.
Its because it doesn't need to be tunable. The framework negotiates
this feature with the drivers... it always enables the feature if the
driver can supp
Raymond LI - Sun Microsystems - Beijing China wrote:
Garrett, pls see my comments inline.
Garrett D'Amore wrote:
Sowmini,
Thanks for updating this proposal, I think we're nearing convergence
on what I'd like to see. ;-)
A few general thoughts:
* we still need to work out the details on a f
> I have a question when reviewing our design doc today. How do we
> document the driver's private properties correctly after Brussel?
Minimally, in the driver's manpage.
--
meem
___
networking-discuss mailing list
networking-discuss@opensolaris.org
Garrett, pls see my comments inline.
Garrett D'Amore wrote:
Sowmini,
Thanks for updating this proposal, I think we're nearing convergence
on what I'd like to see. ;-)
A few general thoughts:
* we still need to work out the details on a few items, including
kstat snapshot collection (you in
[EMAIL PROTECTED] 写道:
Folks,
The Brussels project team has tried to capture existing design
discussions in a first document that is available at
http://opensolaris.org/os/project/brussels/files/brussels.pdf
This (living) document gives an overview of the proposed changes, with
some anecdotal
Garrett,
let me break up the review comments into smaller chunks (some of which
will be addressed by the co-author, Raymond).
On (06/18/07 11:50), Garrett D'Amore wrote:
> * we still need to work out the details on a few items, including kstat
> snapshot collection (you indicated it needs consi
>
> It would be nice of the same user-interface could be used to affect driver
> configuration early in the boot, so that we can handle diskless boot.
>
> That would require being able to parse the persistent state from the
> kernel. (I don't know if the driver.conf parsing support could be reuse
Sowmini,
Thanks for updating this proposal, I think we're nearing convergence on
what I'd like to see. ;-)
A few general thoughts:
* we still need to work out the details on a few items, including kstat
snapshot collection (you indicated it needs consideration), and property
registration.
[EMAIL PROTECTED] wrote:
Folks,
The Brussels project team has tried to capture existing design
discussions in a first document that is available at
http://opensolaris.org/os/project/brussels/files/brussels.pdf
This (living) document gives an overview of the proposed changes, with
some anecd
On (06/13/07 13:13), [EMAIL PROTECTED] wrote:
> >
> >I didn't read that comment as "please add these features to ifconfig
> >on Solaris." Instead, I read it as "please gather information about
> >BSD ifconfig, because that's where more things are configured there."
> >
> >In other words, it was ab
James Carlson wrote:
[EMAIL PROTECTED] writes:
On (06/13/07 11:13), [EMAIL PROTECTED] wrote:
Sowmini,
In the competitive analysis, I'd recommend that you look more
closely at what BSD offers via "ifconfig" as this is typically the
interface used when setting some parameters, such as t
[EMAIL PROTECTED] writes:
> On (06/13/07 11:13), [EMAIL PROTECTED] wrote:
> > Sowmini,
> >
> > In the competitive analysis, I'd recommend that you look more
> > closely at what BSD offers via "ifconfig" as this is typically the
> > interface used when setting some parameters, such as the
> > media
On (06/13/07 11:13), [EMAIL PROTECTED] wrote:
> Sowmini,
>
> In the competitive analysis, I'd recommend that you look more
> closely at what BSD offers via "ifconfig" as this is typically the
> interface used when setting some parameters, such as the
> media type (10BT, 100BT-FDX, etc.) sysctl is
Sowmini,
In the competitive analysis, I'd recommend that you look more
closely at what BSD offers via "ifconfig" as this is typically the
interface used when setting some parameters, such as the
media type (10BT, 100BT-FDX, etc.) sysctl is not as often used
for network device driver settings. O
Folks,
The Brussels project team has tried to capture existing design
discussions in a first document that is available at
http://opensolaris.org/os/project/brussels/files/brussels.pdf
This (living) document gives an overview of the proposed changes, with
some anecdotal references to prototy
60 matches
Mail list logo
