headers
James Carlson | 1 Aug 2009 15:44

Re: [clearview-discuss] Clearview IP Tunneling code-review [due August 12]

Sebastien Roy wrote:
> http://www.opensolaris.org/os/project/clearview/iptun/cr/

I read through all of SFW (not much there) and most in ON.  I glazed
over on dlmgmtd and a fair bit of the kernel changes.

ifconfig.c:

  What happened to the tunnel reality check (IPsec thing)?

  1614: tunnels aren't the only things that lack Ethernet addresses.
  There should probably be another way to do this.

  2424: this looks like a test that belongs in the kernel.

  2476-2477: instead of littering this test everywhere, consider
  having it in dladm_link_open (combination of ':' and
  DATALINK_CLASS_IPTUN is bad) or dladm_iptun_modify, with an
  appropriate error code.

  2536: this will do a close even if the open fails, unlike the very
  similar code at 2482.

  3015: lost the "tabbed" flag, which avoided spurious blank lines.
  It should be added back in.  (And consider putchar('\n'); instead
  of printf("\n");.)

  3909: s/is no assigned/is not assigned/

  4178: this makes the bug at 2536 much more serious; a wrong link
(Continue reading)

Permalink | Reply | 14 comments |
headers
likaijun | 2 Aug 2009 06:12
Favicon

Re: How can I set a right link Aggregations?

Now I set  aggregation and switch side well , 2 e1000g NIC cards to a aggr interface .and use IOmeter  test its
bandwidth is: 
when sequntial read it is more than  210MB/s (script is block is 32k or 64K) .I think it's good .But sequntial
write is less 70MB/s.
and I use a single NIC card (1Gb/s)to test ,sequntial is about 100MB/s . I'm very confused. why read
performance is very good but write performance is very awful.why  2 nic aggr interface performance  is  not
better than 1 nic card?
Thank you!
--

-- 
This message posted from opensolaris.org
Permalink | Reply | 1 comment |
headers
Dale Ghent | 2 Aug 2009 07:53

Re: How can I set a right link Aggregations?


On Aug 2, 2009, at 12:12 AM, likaijun wrote:

> Now I set  aggregation and switch side well , 2 e1000g NIC cards to  
> a aggr interface .and use IOmeter  test its bandwidth is:
> when sequntial read it is more than  210MB/s (script is block is 32k  
> or 64K) .I think it's good .But sequntial write is less 70MB/s.
> and I use a single NIC card (1Gb/s)to test ,sequntial is about 100MB/ 
> s . I'm very confused. why read performance is very good but write  
> performance is very awful.why  2 nic aggr interface performance  is   
> not better than 1 nic card?

You are writing data to disks? From your description, it would seem  
that writes to disk is your bottleneck - topping out at 70MB/s no  
matter how much network bandwidth you throw at it.

If you're trying to test only the network throughput of your  
aggregated set of links, you will certainly want to take the disks out  
of the picture.

/dale
Permalink | Reply | 0 comments |
headers
Darren Reed | 3 Aug 2009 04:11
Picon

PSARC/2006/475 - net_getlifflags and friends

In PSARC/2006/475, net_getlifflags is introduced to retrieve
the logical interface flags, which is fair enough.

Reading the man page, there are some omissions, and possibly
with the case itself too.

First, neither the man page nor the case enumerate what the
flags are. I suspect that the expectation is people will "know"
that the correct flags are found somewhere else.

One of two files needs to be documented for use with this API:
either <net/if.h> or <inet/ip_if.h>

And having chosen which file is to be documented (and thus an
appropriate commitment level given), the relevant flags need
to be pulled out and given the same treatment.

The choice here is do we publish the IPIF_* names or the IFF_*
names? The former makes the documentation easy, the latter means
we need to explicitly state that it is only possible for the
flags listed to be seen.

On a related note, it is also useful to be able to get the
"other" flags, notably those that are PHYI_* and ILLF_*.
At present my need is only for PHYI_* and thus it seems
logical to construct net_getphyflags() to get just those.
But does that leave the ILLF_* flags out in the cold?
Unless someone can come up with a definitive answer on that,
I'm not comfortable with net_getphyflags() being anything
other than a consolidation private interface.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rong Shen | 3 Aug 2009 09:56
Favicon

How to find out your router's DHCP address?

Hello:

I have an Opensolaris behind a router at home. The Opensolaris box runs ftpd. I am trying to let my parents
download pictures from my opensolaris box. I have configured the router to port-forward ftp to this
opensolaris box. I used "traceroute www.yahoo.com" to try to figure out the real DHCP address of my
router. But it seems that the address I got is my ISP's address.

Any suggestions? Thanks.

RS
--

-- 
This message posted from opensolaris.org
Permalink | Reply | 1 comment |
headers
Daniel J. Priem | 3 Aug 2009 09:59
Favicon

Re: How to find out your router's DHCP address?


http://checkip.dyndns.org
Permalink | Reply | 0 comments |
headers
Sebastien Roy | 3 Aug 2009 18:03
Picon

Re: [clearview-discuss] Clearview IP Tunneling code-review [due August 12]


On Sat, 2009-08-01 at 09:44 -0400, James Carlson wrote:
> Sebastien Roy wrote:
> > http://www.opensolaris.org/os/project/clearview/iptun/cr/
> 
> I read through all of SFW (not much there) and most in ON.  I glazed
> over on dlmgmtd and a fair bit of the kernel changes.

Thanks very much!

> 
> ifconfig.c:
> 
>   What happened to the tunnel reality check (IPsec thing)?

Ifconfig no longer outputs or verifies specific policy associated with
the underlying link.  If there's policy associated with the tunnel, it
refers the caller to ipsecconf.

>   1614: tunnels aren't the only things that lack Ethernet addresses.
>   There should probably be another way to do this.

That's true, there's also an escape clause for IFF_VIRTUAL and IFF_IPMP
interfaces a few lines above.  Note that I'm not changing the logic of
the code here, but merely calling a libdladm function instead of a
libinetcfg one to determine if the underlying link is a tunnel.

Are you suggesting that there be a link property that allows one to
derive how to print addresses associated with a given link?  Or
something else?
(Continue reading)

Permalink | Reply | 13 comments |
headers
Sebastien Roy | 3 Aug 2009 20:35
Picon

Re: [clearview-discuss] PSARC/2006/475 - net_getlifflags and friends


On Sun, 2009-08-02 at 19:11 -0700, Darren Reed wrote:
> In PSARC/2006/475, net_getlifflags is introduced to retrieve
> the logical interface flags, which is fair enough.
> 
> Reading the man page, there are some omissions, and possibly
> with the case itself too.
> 
> First, neither the man page nor the case enumerate what the
> flags are. I suspect that the expectation is people will "know"
> that the correct flags are found somewhere else.
> 
> One of two files needs to be documented for use with this API:
> either <net/if.h> or <inet/ip_if.h>
> 
> And having chosen which file is to be documented (and thus an
> appropriate commitment level given), the relevant flags need
> to be pulled out and given the same treatment.
> 
> The choice here is do we publish the IPIF_* names or the IFF_*
> names?

IFF_* flags are already Public and documented in if_tcp(7P) (they also
happen to be the union of the undocumented IPIF_*, ILLF_*, and PHYI_*
flags used for implementation purposes).

> The former makes the documentation easy, the latter means
> we need to explicitly state that it is only possible for the
> flags listed to be seen.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sebastien Roy | 3 Aug 2009 21:31
Picon

Re: [clearview-discuss] Clearview IP Tunneling code-review [due August 12]


On Mon, 2009-08-03 at 12:03 -0400, Sebastien Roy wrote:
> On Sat, 2009-08-01 at 09:44 -0400, James Carlson wrote:
> > Sebastien Roy wrote:
> >   2536: this will do a close even if the open fails, unlike the very
> >   similar code at 2482.
> 
> ACCEPT

I spoke too soon.  This code is correct.  If the open fails,
dladmerr_exit() exits.  We can only reach the dladm_close() if the open
succeeded.  Changing to REJECT.

-Seb
Permalink | Reply | 0 comments |
headers
Rishi Srivatsavai | 3 Aug 2009 21:46
Picon

Re: RBridges code review request

Hello Seb,

Sebastien Roy wrote:
> Rishi,
> 
> On Thu, 2009-07-16 at 13:22 -0400, Rishi Srivatsavai wrote:
>> Code review request for the RBridges project. RBridges project
>> is delivering layer-2 Bridging and TRILL support in Solaris.
>>
>> Webrev for the ON changes (Bridging and TRILL):
>>   http://cr.opensolaris.org/~rishi/rbridges/
> 
> Here are my comments.  I reviewed the bridge module, GLDv3 kernel
> changes, and bfu.  I also took a peek at other files, but did not do a
> full review.

Thanks for the review Seb. My comments in-line below.

> cmd/cmd-inet/usr.lib/bridged/door.c
> 
> * 75-159: Every case in this switch ends with:
> 
>   unlock_engine()
>   (void) door_return();
>   return;
> 
>   These could all be replaced by a "break;" since this is done after
>   the switch.

REJECT. I checked this out but the return args in the door_return() call change
(Continue reading)

Permalink | Reply | 2 comments |

Gmane