IXGB networl driver and locking

[sivakumar.subramani]

Hi all,
 
Same lock is being used in ixgb_intr and ixgb_start. If we get Receive
interrupt while processing Xmit (ixgb_start), Will the calling of
ixgb_intr() handler be delayed as we will not be getting lock in
ixgb_intr since it is already locked in ixgb_start. If it is the case,
are we making it as Half duplex, I mean we are allowing either of one Tx
(or) Rx. Please clarify.
 
488 
ixgb_start  (struct ifnet
  *ifp
 )
489   {
490 
struct adapter   *adapter
  = ifp
 ->if_softc;
491   
492 
IXGB_LOCK  (adapter
 );
493 
ixgb_start_locked 
(ifp  );
494 
IXGB_UNLOCK  (adapter
 );
495 
return;
496   }

 
 
static void
795 
ixgb_intr  (void *arg
 )
796   {
.

IXGB_LOCK  (adapter
 );
.
IXGB_UNLOCK  (adapter
 );

 
Thanks,
~Siva



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.
 
www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: IXGB networl driver and locking

[sivakumar.subramani]

Thanks for the reply. Sorry garbled URL in the previous message. 
 
Actually I was talk between the ixgb_start (Transmit function not the Transmit 
interrupt handler) and rx interrupt handler function ( Where we send the packet 
up using if_input function). 
 
We are using same lock between transmit and Rx_interrupt handler function, Will 
it affect the performance? Can we use seperate locks for these functions to 
increase the performance on multiproccessor system. 
 
For ex, if we assume that ixgb_start function is executed on CPU1 and it create 
the mbuf for transmit. We receive Rx interrupt and CPU2 is scheduled with Rx 
interrupt handler. Since we are holding the lock in ixgb_start function, the Rx 
interrupt handler can not proceed further as it needs ADAPTER LOCK.
 
Am I Correct ??
 
Thanks,
~Siva
 



From: Jack Vogel [mailto:[EMAIL PROTECTED]
Sent: Tue 5/15/2007 1:47 PM
To: SIVAKUMAR SUBRAMANI (WT01 - Computing Storage and Software Products)
Cc: freebsd-net@freebsd.org
Subject: Re: IXGB networl driver and locking



On 5/14/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Same lock is being used in ixgb_intr and ixgb_start. If we get Receive
> interrupt while processing Xmit (ixgb_start), Will the calling of
> ixgb_intr() handler be delayed as we will not be getting lock in
> ixgb_intr since it is already locked in ixgb_start. If it is the case,
> are we making it as Half duplex, I mean we are allowing either of one Tx
> (or) Rx. Please clarify.

What was all this garbled URLs in your message, something is messing
with your content.

In any case, the device only has ONE interrupt registered, it can be
caused by either RX or TX or whatever.

This as well as the em driver has always had a single lock as well,
and, while it could be made more sophisticated, it has been adequate.
The em driver in CURRENT handles some interrupts without the lock.

In any case, the hardware operates independently of the driver to some
extent, processing RX from the wire, and doing the DMA to memory
without the driver being in control, it interrupts when it gets done with
an packet, and even then it can continue.

So, I dont know what your real issue is, but the single adapter lock
does not make things half duplex.

Jack





The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.
 
www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: netgraph with 10Gig interfaces

[sivakumar.subramani]

Hi Mark,

I have bge and fxp interface on the system. I enabled the NETGRAPH by
enabling the NETGRAPH in the config file and compiled the new kernel.
Then, booted with the new kernel.


fxp0: flags=8843 mtu 1500
options=8
inet6 fe80::290:27ff:fe85:8b8c%fxp0 prefixlen 64 scopeid 0x1
inet 17.1.1.150 netmask 0xff00 broadcast 17.255.255.255
ether 00:90:27:85:8b:8c
media: Ethernet autoselect (none)
status: no carrier

bge0: flags=8843 mtu 1500
options=1a
inet6 fe80::2e0:81ff:fe29:f38d%bge0 prefixlen 64 scopeid 0x3
inet 10.114.52.152 netmask 0xff00 broadcast 10.114.52.255
ether 00:e0:81:29:f3:8d
media: Ethernet autoselect (100baseTX )
status: active

Even then I could not see the above interfaces listed in the output of
the list command of ngctl.

+ list -l
There are 2 total nodes:
  Name: ngctl1088   Type: socket  ID: 0007   Num hooks:
0
  Name:Type: eiface  ID: 0004   Num hooks:
0
+ list -n
There are 1 total named nodes:
  Name: ngctl1088   Type: socket  ID: 0007   Num hooks:
0
+


But as per the document in the below link it is mentioned that network
interface by default should be listed in the output.
http://ezine.daemonnews.org/23/netgraph.html

Is that means these drivers are not supporting the netgraph?

Thanks,
~Siva

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of mark
Sent: Monday, August 14, 2006 9:14 PM
To: Gleb Smirnoff; Christian Brueffer; freebsd-net@FreeBSD.org
Subject: Re: netgraph with 10Gig interfaces

Gleb Smirnoff wrote:
> On Mon, Aug 14, 2006 at 08:20:25AM -0700, mark wrote:
> m> It sounds like there's an assumption it's a driver problem.  Note
> m> that the intel 10Gig driver (from Interl's website) also does not
work
> m> with netgraph (works fine otherwise though)
> m>
> m> Is there something that drivers need to do to support netgraph?
>
> All Ethernet interfaces should instantly be supported by ng_ether(4).
> ATM, I have no idea why you have problems with Neterion and Intel
> interfaces.

That's what I thought.  Is there anything I can send along that
would be of use, such as ngctl output with debug on?

Mark

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: netgraph with 10Gig interfaces

[sivakumar.subramani]

Hi Mark,

>>This snippet is from a script, and the variables '$if1' and '$if2'
>>are set to the interfaces.  In effect, the 'connect' lines above are
actually (for Neterion 10Gig driver):
>>ngctl connect xge0: ngeth0:lower lower many0 ngctl connect xge1:
ngeth0:lower lower many0

Can You please send me the steps/command that you used to test the
Neterion card. I means what are the argument that you gave for msg
command.

Info on how did you verify the traffic flow?

Thanks,
~Siva

-Original Message-
From: Gleb Smirnoff [mailto:[EMAIL PROTECTED]
Sent: Friday, August 18, 2006 3:26 PM
To: SIVAKUMAR SUBRAMANI (WT01 - Computing Systems & Storage)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; freebsd-net@FreeBSD.org
Subject: Re: netgraph with 10Gig interfaces

On Thu, Aug 17, 2006 at 06:21:50PM +0530, [EMAIL PROTECTED]
wrote:
s> I have bge and fxp interface on the system. I enabled the NETGRAPH by

s> enabling the NETGRAPH in the config file and compiled the new kernel.
s> Then, booted with the new kernel.
s>
s>
s> fxp0: flags=8843 mtu 1500
s> options=8
s> inet6 fe80::290:27ff:fe85:8b8c%fxp0 prefixlen 64 scopeid 0x1
s> inet 17.1.1.150 netmask 0xff00 broadcast 17.255.255.255
s> ether 00:90:27:85:8b:8c
s> media: Ethernet autoselect (none)
s> status: no carrier
s>
s> bge0: flags=8843 mtu 1500
s> options=1a
s> inet6 fe80::2e0:81ff:fe29:f38d%bge0 prefixlen 64 scopeid 0x3
s> inet 10.114.52.152 netmask 0xff00 broadcast 10.114.52.255
s> ether 00:e0:81:29:f3:8d
s> media: Ethernet autoselect (100baseTX )
s> status: active
s>
s> Even then I could not see the above interfaces listed in the output
s> of the list command of ngctl.
s>
s> + list -l
s> There are 2 total nodes:
s>   Name: ngctl1088   Type: socket  ID: 0007   Num
hooks:
s> 0
s>   Name:Type: eiface  ID: 0004   Num
hooks:
s> 0
s> + list -n
s> There are 1 total named nodes:
s>   Name: ngctl1088   Type: socket  ID: 0007   Num
hooks:
s> 0
s> +
s>
s>
s> But as per the document in the below link it is mentioned that
s> network interface by default should be listed in the output.
s> http://ezine.daemonnews.org/23/netgraph.html
s>
s> Is that means these drivers are not supporting the netgraph?

No. You need either kldload ng_ether or add NETGRAPH_ETHER to kernel
config.

--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Testing on network interface - promisc mode.

[sivakumar.subramani]

Hi,



I was using following steps to test the promisc mode on the network
interface on my system on FreeBSD 6.1.



-  On machine A, I updated the arp table with the a dummy MAC
address (aa:bb:cc:dd:ee:ff) for the remote interface on Machine B.

#arp -s 17.1.1.110 aa:bb:cc:dd:ee:f



-  On Machine B, I enabled promisc mode for the test N/W
interface.

#ifconfig  promisc



- Started tcpdump on Machine A, for capturing the packets.



-  On Machine A, I ping to the remote Interface of the Machine B

#ping -c2 17.1.1.110

-  Ping went through fine and Tcpdump is displaying both ICMP
request and ICMP reply.



I could understand that machine B receives ICMP request as promisc mode
is enabled. But it  was not suppose to send ICMP reply as the packet was
not intended for this machine (I mean the ICMP REQUEST PACKET contain
some dummy MAC address). It was supposed to be discarded.



After testing the above steps, I could see the ICMP REPLY from MACHINE B
and ICMP REPLY contain original Mac address in the Source MAC address
field in the Ethernet header.



Please let me know whether the above behavior is correct and acceptable.



Thanks,

~Siva






The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reading a configuration file from a driver code during intialization.

[sivakumar.subramani]

Hi all,



For our driver we have following requirement. We have a configuration
file that will be updated by the user and while loading the driver, the
initialization code should read the configuration file to get the value
and use it in the driver code.



Is there is any way to read a configuration file from driver code?



Currently I have written a small kernel module that will create a sysctl
variable and update with a default value. After loading this module,
using shell scripts, I read the configuration file and get the user set
values and update the sysctl variable in that value. Then I will load my
driver where I read the sysctl variable to get the required values set
by the user in the configuration file.



Is there is any other solution to the above problem?



Actually I am looking for some thing similar to Module loadable
parameters in the Linux Device Driver.



Thanks,

~Siva




The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Reading a configuration file from a driver code during intialization.

[sivakumar.subramani]

Hi Mark,



As I mentioned in the previous mail, the main issue is to read a
Configuration parameter file from driver code. I am already using Sysctl
variables as mentioned below,



Currently I have written a small kernel module that will create a sysctl
variable and update with a default value. After loading this module,
using shell scripts, I read the configuration file and get the user set
values and update the sysctl variable in that value. Then I will load my
driver where I read the sysctl variable to get the required values set
by the user in the configuration file.



This is a round about way. Is there is any other way to read a
configuration file from Driver code.





Thanks,

~Siva

-Original Message-
From: John-Mark Gurney [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 14, 2006 9:43 PM
To: SIVAKUMAR SUBRAMANI (WT01 - Computing Systems & Storage)
Cc: freebsd-net@FreeBSD.org
Subject: Re: Reading a configuration file from a driver code during
intialization.



[EMAIL PROTECTED] wrote this message on Thu, Sep 14, 2006 at
12:16 +0530:

> Is there is any other solution to the above problem?

>

>

>

> Actually I am looking for some thing similar to Module loadable

> parameters in the Linux Device Driver.



look at kenv...  It lets you set arbitrary values and access them in

the kernel...  you can use the TUNABLE_* macros provided by sys/kernel.h

to make accessing them easier...



If the variables need to change at run time, look at SYSCTL...



--

  John-Mark GurneyVoice: +1 415 225 5579



 "All that I will do, has been done, All that I have, has not."




The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

How to access the values of the kenv variables in driver code?

[sivakumar.subramani]

Hi all,



I would like to have some of the configuration parameters of my driver
to be present as part of the /boot/device.hints file. After adding a
variable I could see that variable and it's value as part of kevn's
ouput.



Can any one please let me know how to access the value of these
variables in my drive code?



Thanks,

~Siva




The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: TSO patch for current

[sivakumar.subramani]

Is the TSO patch is checked in to the current?

Thanks,
~Siva

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jack Vogel
Sent: Saturday, September 02, 2006 4:21 AM
To: freebsd-net; freebsd-current
Subject: RFC: TSO patch for current

This is a patch for the stack and the em driver to enable TSO
on CURRENT. Previously I had problems getting it to work, but
this is functional.

I should note that CURRENT is being a pain right now, when
I comment out em in the config the kernel panics coming up,
so I had to substitute this code into the tree. Rather bizarre :)

I have this functionality running on a 6.1 based system, and
our test group is already testing against that driver, so far
things are looking good.

I have designed it so the driver can continue to be built
without support. There is also a sysctl in the stack code
so you can set net.inet.tcp.tso_enable on or off and
compare.

I know there may be some refinements to add in, but I
would like to get this into CURRENT as a start.

Comments?

Jack


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Query on SPIN Mutex in FreeBSD.

[sivakumar.subramani]

Hi,



I have a query regarding the mutex lock in network driver,



When I was browsing all network drivers in FreeBSD, I found none of the
drivers are using MTX_SPIN, instead all of them are using MTX_DEF. When
I read the man page of the mutex, it is mentioned that we need to use
MTX_SPIN in primary interrupt code. Is that mean that I need to hold the
MTX_SPIN lock in ISR routine? I am facing a conflicting issue regarding
the DTR usage (freeing in Stop and Use it ISR) between Stop and ISR
routine. I want to know whether I can use a MTX_SPIN lock between these
functions. I mean I will hold the SPIN_LOCK in ISR and in stop entry
point function such that the freeing and the usage of DTR between STOP
and ISR is synchronized. Is that correct approach?





Any suggestion please?



Thanks,

~Siva




The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: RFC: TSO patch for current

[sivakumar.subramani]

Hi Jack,
Do you the patch for 6.0 FreeBSD kernel? If so can you please send it
me. I would like to test TSO on my system.

Thanks,
~Siva

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jack Vogel
Sent: Wednesday, September 06, 2006 3:53 AM
To: Andre Oppermann
Cc: freebsd-net; freebsd-current
Subject: Re: RFC: TSO patch for current

On 9/5/06, Andre Oppermann <[EMAIL PROTECTED]> wrote:
> Jack Vogel wrote:
> > On 9/5/06, Andre Oppermann <[EMAIL PROTECTED]> wrote:
> >> Prafulla Deuskar wrote:
> >> > Your patch looks good and is the way to go.
> >> >
> >> > So after Jack confirms that your patch works with the em driver
> >> > would you commit to to -current?
> >>
> >> Absolutely.  :-)
> >>
> >> > The driver related changes can follow..
> >> >
> >> > Later we also need to fix ifconfig so that user can
> >> > enable/disable
> >> TSO on the interface.
> >>
> >> I'll do that together with the TSO code.
> >
> > OK, I've built and done some touch testing of this. I like it, the
> > driver has some counters of the number of TSO bursts it does, and I
> > think I see more per netperf test with your patch than mine.
> >
> > Hard to do real performance testing with all that WITNESS stuff in,
> > but I will be making a 6.1 version of your patch to test with since
> > I have my driver running on that anyway.
>
> You can disable WITNESS and INVARIANTS pretty easily in -current and
> get the full performance with it.

Last time I tried that I think the kernel wouldnt build, but that was
like 6 months ago, so I just kicked off a build with this stuff off, and
we'll see how it looks :)

> > If you do the ifconfig changes there will need to be a small amount
> > of code added to em_ioctl() but it should be trivial.
> >
> > You want me to reissue a driver patch with changes for your code?
>
> Yes, please do so.  I've got a dual-em card which I can test with
myself.

OK, attached new patch, this one even has the ioctl change so when you
get the ifconfig change in it will be ready.

Cheers,

Jack


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Zoneli State / Nttcp client.

[sivakumar.subramani]

Hi,

I have a script where we start a nttcp for some 500 nttcp client in back
ground. After some time I could see the nttcp clients are listed in the
TOP command as "Zoneli" state. Can any one please let me know what is
meant by Zoneli state?

Test Script:
=
count=1
while [ $count -le 2000 ]
do
ifconfig xge1 17.1.1.25 promisc up
./nttcp -t -l65536 -w227 -P120 17.1.1.152 &
echo "count is $count"
count=`expr $count + 1`
done

Thanks,
~Siva



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.comast pid:  6790;  load averages:  0.00,  0.00,  0.28 
up 0+00:56:58  17:57:26
229 processes: 1 starting, 1 running, 227 sleeping
CPU states:  0.4% user,  0.0% nice,  0.4% system,  1.1% interrupt, 98.1% idle
Mem: 48M Active, 6368K Inact, 138M Wired, 9184K Buf, 804M Free
Swap: 487M Total, 487M Free

  PID USERNAME  THR PRI NICE   SIZERES STATETIME   WCPU COMMAND
 6664 root1   60 0K 0K START0:04  0.00% login
 6756 root1  960  2700K  1976K select   0:02  0.00% top
  642 root1   60  1272K   888K ttywri   0:00  0.00% vmstat
  304 root1  960  1292K   852K select   0:00  0.00% syslogd
  540 root1  960  3152K  2260K select   0:00  0.00% telnetd
  525 root1 -160  3152K  2232K zoneli   0:00  0.00% telnetd
 6790 root1  960  2636K  1912K RUN  0:00  0.00% top
 6663 root1 -160  3152K  2260K zoneli   0:00  0.00% telnetd
 5870 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 6329 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 6221 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
  662 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
  668 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
  512 root1   80  1620K  1324K wait 0:00  0.00% login
 1382 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
  511 root1 -160  3152K  2232K zoneli   0:00  0.00% telnetd
  545 root1  200  3872K  2632K pause0:00  0.00% csh
 1433 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 1418 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 1415 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 5747 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 6760 root1  960  3152K  2260K select   0:00  0.00% telnetd
 3653 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 1211 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 6765 root1  200  3872K  2636K pause0:00  0.00% csh
  516 root1  200  3868K  2600K pause0:00  0.00% csh
  530 root1   50  3868K  2600K ttyin0:00  0.00% csh
  500 root1   80  1592K  1280K wait 0:00  0.00% login
 6632 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 6452 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 1667 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 3578 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 1814 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 6413 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
 1562 214748361 -160  1332K  1008K zoneli   0:00  0.00% nttcp
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: RFC: TSO patch for current

[sivakumar.subramani]

Hi,

I have a patch that I got from the mailing list. But it does not contain
the changes that adds   tso_segsz to mbuffer header structure.

Can any one please send me the latest patch for TSO that contains stack
changes?

Thanks,
~Siva

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jack Vogel
Sent: Wednesday, September 06, 2006 3:53 AM
To: Andre Oppermann
Cc: freebsd-net; freebsd-current
Subject: Re: RFC: TSO patch for current

On 9/5/06, Andre Oppermann <[EMAIL PROTECTED]> wrote:
> Jack Vogel wrote:
> > On 9/5/06, Andre Oppermann <[EMAIL PROTECTED]> wrote:
> >> Prafulla Deuskar wrote:
> >> > Your patch looks good and is the way to go.
> >> >
> >> > So after Jack confirms that your patch works with the em driver
> >> > would you commit to to -current?
> >>
> >> Absolutely.  :-)
> >>
> >> > The driver related changes can follow..
> >> >
> >> > Later we also need to fix ifconfig so that user can
> >> > enable/disable
> >> TSO on the interface.
> >>
> >> I'll do that together with the TSO code.
> >
> > OK, I've built and done some touch testing of this. I like it, the
> > driver has some counters of the number of TSO bursts it does, and I
> > think I see more per netperf test with your patch than mine.
> >
> > Hard to do real performance testing with all that WITNESS stuff in,
> > but I will be making a 6.1 version of your patch to test with since
> > I have my driver running on that anyway.
>
> You can disable WITNESS and INVARIANTS pretty easily in -current and
> get the full performance with it.

Last time I tried that I think the kernel wouldnt build, but that was
like 6 months ago, so I just kicked off a build with this stuff off, and
we'll see how it looks :)

> > If you do the ifconfig changes there will need to be a small amount
> > of code added to em_ioctl() but it should be trivial.
> >
> > You want me to reissue a driver patch with changes for your code?
>
> Yes, please do so.  I've got a dual-em card which I can test with
myself.

OK, attached new patch, this one even has the ioctl change so when you
get the ifconfig change in it will be ready.

Cheers,

Jack


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Regarding Jumbo frame implementation in bge

[sivakumar.subramani]

Hi,

In bge driver, we have BGE_JUMBO_FRAMELEN defined to 9018.
if_bgereg.h:#define BGE_JUMBO_FRAMELEN  9018

This macro is used to allocate the memory for jumbo buffer. If I have a
MTU size of 2000, still bge will allocate the jumbo buffer of size
BGE_JUMBO_FRAMELEN. Instead can we make the size to be depend on the
MTU. I mean instead of using BGE_JUMBO_FRAMELEN macro we can use MTU +
IP header + CRC for Jumbo buffer size.

Any reason for allocating a hard coded 9018 size all Jumbo MTU frame
(whether it is 9000 / 2000)?

Thanks,
~Siva



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"