Re: Test tools for new network driver

2011-08-19 Thread Ben Hutchings 
On Fri, 2011-08-19 at 11:04 +0100, Ben Gray wrote:
> Hi,
> 
>  I'm not sure if this the right list to post to, but here goes ...
> 
>  I'm currently writing a driver for the SMSC LAN95xx range of USB to 
> Ethernet adapter chips 
> (http://www.smsc.com/index.php?tid=300&pid=135&tab=1). The basic RX/TX 
> works and now I'm trying to get the H/W checksum offload working, 
> however I've come across some problems with the H/W implementation, e.g. 
> it doesn't work with small (<64 byte) packets.
> 
>  So I was wondering if anyone knows of any test tools I can use to 
> fire all the different unusual sort of packets at the interface to see 
> how the H/W csum reacts, i.e. runt packets, packets with IP options, 
> IPv6 packets with extension headers, etc.

There are various commercial tools and test suites, and I would expect
that most vendors of network controllers and IP blocks have their own
test suites that attempt to cover this.  I know Solarflare has used
tools from Oktet Labs (see )
among others.

>  Another question I had was; is there a kernel function to generate 
> a random MAC address ? Or is there a FreeBSD (or FOSS equivalent) 
> Ethernet manufacturer ID I could use for randomly generated MAC addresses ?
[...]

You can use any (almost) any address with byte 0 bit 0 cleared (not
multicast) and byte 0 bit 1 set (locally assigned).  I don't know
whether FreeBSD has a function for this, but Linux has one which just
gets 6 random bytes and then changes the first byte to conform to this.

There are a small number of old OUIs which should be avoided; see
.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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

Re: kern/159927: Support of ethernet devices

2011-08-19 Thread gjb 
Synopsis: Support of ethernet devices

Responsible-Changed-From-To: freebsd-www->freebsd-net
Responsible-Changed-By: gjb
Responsible-Changed-When: Fri Aug 19 20:42:57 UTC 2011
Responsible-Changed-Why: 
Over to -net, not a www PR.


http://www.freebsd.org/cgi/query-pr.cgi?pr=159927
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/158156: commit references a PR

2011-08-19 Thread dfilter service 
The following reply was made to PR kern/158156; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/158156: commit references a PR
Date: Fri, 19 Aug 2011 19:13:11 + (UTC)

 Author: marius
 Date: Fri Aug 19 19:12:58 2011
 New Revision: 225014
 URL: http://svn.freebsd.org/changeset/base/225014
 
 Log:
   r221812 reveals that at least some Broadcom PHYs default to being not only
   isolated but also powered down after a reset and while they just work fine
   [sic] when both is the case they don't if they are only deisolate but still
   powered down. So in order to put PHYs in an overall normal operation mode
   for the common case, ensure in mii_phy_reset() that they are not powered
   down after a reset. Unfortunately, this only helps in case of BCM5421,
   while BCM5709S apparently only work when they remain isolated and powered
   down after a reset. So don't call mii_phy_reset() in brgphy_reset() and
   implement the reset locally leaving the problematic bits alone. Effectively
   this bypasses r221812 for brgphy(4).
   Thanks to Justin Hibbits for doing a binary search in order to identify
   the problematic commit.
   
   PR:  157405, 158156
   Reviewed by: yongari (mii_phy_reset() part)
   Approved by: re (kib)
   MFC after:   3 days
 
 Modified:
   head/sys/dev/mii/brgphy.c
   head/sys/dev/mii/mii_physubr.c
 
 Modified: head/sys/dev/mii/brgphy.c
 ==
 --- head/sys/dev/mii/brgphy.c  Fri Aug 19 15:21:13 2011(r225013)
 +++ head/sys/dev/mii/brgphy.c  Fri Aug 19 19:12:58 2011(r225014)
 @@ -876,10 +876,22 @@ brgphy_reset(struct mii_softc *sc)
struct bge_softc *bge_sc = NULL;
struct bce_softc *bce_sc = NULL;
struct ifnet *ifp;
 -  int val;
 +  int i, val;
  
 -  /* Perform a standard PHY reset. */
 -  mii_phy_reset(sc);
 +  /*
 +   * Perform a reset.  Note that at least some Broadcom PHYs default to
 +   * being powered down as well as isolated after a reset but don't work
 +   * if one or both of these bits are cleared.  However, they just work
 +   * fine if both bits remain set, so we don't use mii_phy_reset() here.
 +   */
 +  PHY_WRITE(sc, BRGPHY_MII_BMCR, BRGPHY_BMCR_RESET);
 +
 +  /* Wait 100ms for it to complete. */
 +  for (i = 0; i < 100; i++) {
 +  if ((PHY_READ(sc, BRGPHY_MII_BMCR) & BRGPHY_BMCR_RESET) == 0)
 +  break;
 +  DELAY(1000);
 +  }
  
/* Handle any PHY specific procedures following the reset. */
switch (sc->mii_mpd_oui) {
 
 Modified: head/sys/dev/mii/mii_physubr.c
 ==
 --- head/sys/dev/mii/mii_physubr.c Fri Aug 19 15:21:13 2011
(r225013)
 +++ head/sys/dev/mii/mii_physubr.c Fri Aug 19 19:12:58 2011
(r225014)
 @@ -273,8 +273,8 @@ mii_phy_reset(struct mii_softc *sc)
DELAY(1000);
}
  
 -  /* NB: a PHY may default to isolation. */
 -  reg &= ~BMCR_ISO;
 +  /* NB: a PHY may default to being powered down and/or isolated. */
 +  reg &= ~(BMCR_PDOWN | BMCR_ISO);
if ((sc->mii_flags & MIIF_NOISOLATE) == 0 &&
((ife == NULL && sc->mii_inst != 0) ||
(ife != NULL && IFM_INST(ife->ifm_media) != sc->mii_inst)))
 ___
 svn-src-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Test tools for new network driver

2011-08-19 Thread YongHyeon PYUN 
On Fri, Aug 19, 2011 at 11:04:18AM +0100, Ben Gray wrote:
> Hi,
> 
> I'm not sure if this the right list to post to, but here goes ...
> 
> I'm currently writing a driver for the SMSC LAN95xx range of USB to 
> Ethernet adapter chips 
> (http://www.smsc.com/index.php?tid=300&pid=135&tab=1). The basic RX/TX 
> works and now I'm trying to get the H/W checksum offload working, 
> however I've come across some problems with the H/W implementation, e.g. 
> it doesn't work with small (<64 byte) packets.
> 

In old days, it was common that see hardware issues where TX
checksum offloading does not work unless you manually pad the frame
to satisfy minimal frame size(60 bytes).  Check if the controller
has auto-padding feature or try manually pad it.

Note, current USB stack lacks TX/RX checksum offloading support. I
have a working patch which would give you some idea.

uether patch:
http://people.freebsd.org/~yongari/axe/usb_ethernet.diff4
axe(4) to enable TX/RX checksum offloading:
http://people.freebsd.org/~yongari/axe/axe_csum.diff4

> So I was wondering if anyone knows of any test tools I can use to 
> fire all the different unusual sort of packets at the interface to see 
> how the H/W csum reacts, i.e. runt packets, packets with IP options, 
> IPv6 packets with extension headers, etc.
> 

I'm not aware of tools that can do you mentioned above. However, I
guess you can generate many test cases with existing tools(ping,
netperf etc).

> Another question I had was; is there a kernel function to generate 
> a random MAC address ? Or is there a FreeBSD (or FOSS equivalent) 
> Ethernet manufacturer ID I could use for randomly generated MAC addresses ?
> 

See sk(4) how it uses randomly generated station address.

> The primarily purpose is for the range of Texas Instruments ARM 
> development boards (Pandaboard & Beagleboard), however there does exist 
> at least one USB dongle you can buy for the PC which uses this chipset.
> 
> Thanks in advance,
> Ben
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Test tools for new network driver

2011-08-19 Thread Kevin Oberman 
 On Fri, Aug 19, 2011 at 4:00 AM, Adrian Chadd  wrote:
> Cool!
>
> I don't think there's a random MAC address function call; I see
> homebrewed versions of those in various drivers. :)
>
> I'm not sure about a packet fuzz tester; but that sounds like it'd be
> a great addition to the tools/ directory.

/dev/random will do fine, but please be aware that the Ethernet
(actually 802.1) spec says
that the second bit on the wire (the bit after the "group address" bit
(better known as the
multicast) bit should be set for all "locally assigned" MAC addresses,
so you should OR the first byte if the address with 0x2.

This requirement is often overlooked and I don't think the MAC police
will haul you off to
jail(8) if you ignore it, but I do like to remind people that the rule
is there. (OK, I am probably a bit OCD.)

> On 19 August 2011 18:04, Ben Gray  wrote:
>> Hi,
>>
>>I'm not sure if this the right list to post to, but here goes ...
>>
>>I'm currently writing a driver for the SMSC LAN95xx range of USB to
>> Ethernet adapter chips
>> (http://www.smsc.com/index.php?tid=300&pid=135&tab=1). The basic RX/TX works
>> and now I'm trying to get the H/W checksum offload working, however I've
>> come across some problems with the H/W implementation, e.g. it doesn't work
>> with small (<64 byte) packets.
>>
>>So I was wondering if anyone knows of any test tools I can use to fire
>> all the different unusual sort of packets at the interface to see how the
>> H/W csum reacts, i.e. runt packets, packets with IP options, IPv6 packets
>> with extension headers, etc.
>>
>>Another question I had was; is there a kernel function to generate a
>> random MAC address ? Or is there a FreeBSD (or FOSS equivalent) Ethernet
>> manufacturer ID I could use for randomly generated MAC addresses ?
>>
>>The primarily purpose is for the range of Texas Instruments ARM
>> development boards (Pandaboard & Beagleboard), however there does exist at
>> least one USB dongle you can buy for the PC which uses this chipset.
>>
>> Thanks in advance,
>> Ben

-- 
R. Kevin Oberman, Network Engineer - Retired
E-mail: kob6...@gmail.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Test tools for new network driver

2011-08-19 Thread Adrian Chadd 
Cool!

I don't think there's a random MAC address function call; I see
homebrewed versions of those in various drivers. :)

I'm not sure about a packet fuzz tester; but that sounds like it'd be
a great addition to the tools/ directory.



adrian

On 19 August 2011 18:04, Ben Gray  wrote:
> Hi,
>
>    I'm not sure if this the right list to post to, but here goes ...
>
>    I'm currently writing a driver for the SMSC LAN95xx range of USB to
> Ethernet adapter chips
> (http://www.smsc.com/index.php?tid=300&pid=135&tab=1). The basic RX/TX works
> and now I'm trying to get the H/W checksum offload working, however I've
> come across some problems with the H/W implementation, e.g. it doesn't work
> with small (<64 byte) packets.
>
>    So I was wondering if anyone knows of any test tools I can use to fire
> all the different unusual sort of packets at the interface to see how the
> H/W csum reacts, i.e. runt packets, packets with IP options, IPv6 packets
> with extension headers, etc.
>
>    Another question I had was; is there a kernel function to generate a
> random MAC address ? Or is there a FreeBSD (or FOSS equivalent) Ethernet
> manufacturer ID I could use for randomly generated MAC addresses ?
>
>    The primarily purpose is for the range of Texas Instruments ARM
> development boards (Pandaboard & Beagleboard), however there does exist at
> least one USB dongle you can buy for the PC which uses this chipset.
>
> Thanks in advance,
> Ben
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Test tools for new network driver

2011-08-19 Thread Ben Gray 

Hi,

I'm not sure if this the right list to post to, but here goes ...

I'm currently writing a driver for the SMSC LAN95xx range of USB to 
Ethernet adapter chips 
(http://www.smsc.com/index.php?tid=300&pid=135&tab=1). The basic RX/TX 
works and now I'm trying to get the H/W checksum offload working, 
however I've come across some problems with the H/W implementation, e.g. 
it doesn't work with small (<64 byte) packets.


So I was wondering if anyone knows of any test tools I can use to 
fire all the different unusual sort of packets at the interface to see 
how the H/W csum reacts, i.e. runt packets, packets with IP options, 
IPv6 packets with extension headers, etc.


Another question I had was; is there a kernel function to generate 
a random MAC address ? Or is there a FreeBSD (or FOSS equivalent) 
Ethernet manufacturer ID I could use for randomly generated MAC addresses ?


The primarily purpose is for the range of Texas Instruments ARM 
development boards (Pandaboard & Beagleboard), however there does exist 
at least one USB dongle you can buy for the PC which uses this chipset.


Thanks in advance,
Ben
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression]

2011-08-19 Thread Paul Herman 
The following reply was made to PR kern/127050; it has been noted by GNATS.

From: Paul Herman 
To: bug-follo...@freebsd.org
Cc: Wouter de Jong , Jacek Zapala 
Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces 
[regression]
Date: Fri, 19 Aug 2011 10:13:46 +0200

 This is a multi-part message in MIME format.
 --010305010708060807000808
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 This one's been bothering me too, so I setup a test machine yesterday to 
 figure out what's going on.  I see two problems here.
 
 First of all, in6_ifinit() (called via in6_control() SIOCAIFADDR_IN6 -> 
 in6_update_ifa()) only calls carp_ioctl() on the first IPv6 address. 
 Whereas in the v4 case, carp_ioctl() does get called by in_ifinit() 
 every time.
 
 Second of all, carp_set_addr6() (called via carp_ioctl()) only joins the 
 CARP multicast group AND the solicitation group with the first address.
 
 The attached patch against 8-STABLE fixes these issues, alias IPs are 
 now pingable.  I have not tested actual carp functionality with a 2nd 
 BACKUP carp.  What this patch doesn't address is group membership 
 removal when alias IPs are deleted (apparently also broken.)
 
 Try it out, if it works for you guys, maybe someone more familiar with 
 in[6]_control() can chime in here and comment on a *real* way to fix 
 this issue.  :-)
 
 Cheers,
 
 -Paul.
 
 --010305010708060807000808
 Content-Type: application/gzip;
  name="carp_ip6_alias.patch.gz"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename="carp_ip6_alias.patch.gz"
 
 H4sICDwXTk4CA2NhcnBfaXA2X2FsaWFzLnBhdGNoAJVVa0+jQBT9TH/F9UsDHbDQWvramhof
 CVlfsZpN1hiCCDobYAhD42Pd/753mNIHtlZJyuvee+7pOXcGwzCAv/JmEuQUf3aTJvauv8sy
 +qi0TMsyzJ5h9cHsDszeoG3umuUBRJxrhJA19dXS/qDT/lA6HoNhdffaehfI7Doe16AGCvWM
 feq53sNDBiNocMQcYsBQaAgqDT2fTZMcfozAgnodaJhieuhS5ueRBn9rpMirJL6/zxPz1zSA
 0Qick2v38ODqUluLAooSZBkTDNTGahShUx0mzsXhxDk5ODq60kH1BVs316inDUWtoFDUz7AU
 nkYvKsegsSp5k6au72XpetU7rUHH3qb6AqJSbXUG5gbh7a6p91F4cbWsQnmF59nUz0FAuci/
 4dNwuHiNLuDbwpQG9XRxclcTUtuNWZpTlnCMxjZD7ercN/a574rHIVqzBBZPo5xiYmLHlTZF
 E+m6QtFB9pzoUKgp5oDg29IacygnBtV2zm3XmbjCD/fmfHJ5fOicOMdHal3MD3IogTXhiBy+
 Vl/vieFrW7otJfg3h9uZEU9EDbdFkaFspG8UnuN/xDHBswz6Hs9RohR54lkyVZoN+MNoAmLy
 YJ4GokvAUbdmuTA6emuvWBnFTcFOUR5ZzsCPAi+ZpsNqzyC+DzL+RNNb8070nAm7nJNM46U8
 ToigbixYcRZRn+bBw3pqmHn/FmRMrSO4Dpy+BSxU8V4Tg42dcPVzKbNlSxZPOY6Dar6Eodn6
 kNRu3Vp30sYPgVZZHanWusK2iFe8XQlXa3q3VoEpuMiY2E6wkgc591kazP5VsbrPb05PNdjB
 bE2kVoSXwDGCibziuZzIYjR8V6gp9wkJKvLkfawj5ry/3CM2tFjrrbXw1tjmrRxo8lV7ySfu
 ki+YSzZ4Sz63lnzfWbLZWPJlX0lVc7LqKvm2qWTZ03Xw2xwlWwwl5e5UfpHEZj37xOB2jTix
 F0XMV2fmiT1c0+Gs+NDpIgvwOHN/HTjXFz/fz9zfx1cXSPw/VIIrJwgIAAA=
 --010305010708060807000808--
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Multiqueue support for bpf

2011-08-19 Thread Takuya ASADA 
Any comments or suggestions?

2011/8/18 Takuya ASADA :
> 2011/8/16 Vlad Galu :
>> On Aug 16, 2011, at 11:50 AM, Vlad Galu wrote:
>>> On Aug 16, 2011, at 11:13 AM, Takuya ASADA wrote:
 Hi all,

 I implemented multiqueue support for bpf, I'd like to present for review.
 This is a Google Summer of Code project, the project goal is to
 support multiqueue network interface on BPF, and provide interfaces
 for multithreaded packet processing using BPF.
 Modern high performance NICs have multiple receive/send queues and RSS
 feature, this allows to process packet concurrently on multiple
 processors.
 Main purpose of the project is to support these hardware and get
 benefit of parallelism.

 This provides following new APIs:
 - queue filter for each bpf descriptor (bpf ioctl)
   - BIOCENAQMASK    Enables multiqueue filter on the descriptor
   - BIOCDISQMASK    Disables multiqueue filter on the descriptor
   - BIOCSTRXQMASK    Set mask bit on specified RX queue
   - BIOCCRRXQMASK    Clear mask bit on specified RX queue
   - BIOCGTRXQMASK    Get mask bit on specified RX queue
   - BIOCSTTXQMASK    Set mask bit on specified TX queue
   - BIOCCRTXQMASK    Clear mask bit on specified TX queue
   - BIOCGTTXQMASK    Get mask bit on specified TX queue
   - BIOCSTOTHERMASK    Set mask bit for the packets which not tied
 with any queues
   - BIOCCROTHERMASK    Clear mask bit for the packets which not tied
 with any queues
   - BIOCGTOTHERMASK    Get mask bit for the packets which not tied
 with any queues

 - generic interface for getting hardware queue information from NIC
 driver (socket ioctl)
   - SIOCGIFQLEN    Get interface RX/TX queue length
   - SIOCGIFRXQAFFINITY    Get interface RX queue affinity
   - SIOCGIFTXQAFFINITY    Get interface TX queue affinity

 Patch for -CURRENT is here, right now it only supports igb(4),
 ixgbe(4), mxge(4):
 http://www.dokukino.com/mq_bpf_20110813.diff

 And below is performance benchmark:

 
 I implemented benchmark programs based on
 bpfnull(//depot/projects/zcopybpf/utils/bpfnull/),

 test_sqbpf measures bpf throughput on one thread, without using multiqueue 
 APIs.
 http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2011/mq_bpf/src/tools/regression/bpf/mq_bpf/test_sqbpf/test_sqbpf.c

 test_mqbpf is multithreaded version of test_sqbpf, using multiqueue APIs.
 http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2011/mq_bpf/src/tools/regression/bpf/mq_bpf/test_mqbpf/test_mqbpf.c

 I benchmarked with six conditions:
 - benchmark1 only reads bpf, doesn't write packet anywhere
 - benchmark2 writes packet on memory(mfs)
 - benchmark3 writes packet on hdd(zfs)
 - benchmark4 only reads bpf, doesn't write packet anywhere, with zerocopy
 - benchmark5 writes packet on memory(mfs), with zerocopy
 - benchmark6 writes packet on hdd(zfs), with zerocopy

> From benchmark result, I can say the performance is increased using
 mq_bpf on 10GbE, but not on GbE.

 * Throughput benchmark
 - Test environment
 - FreeBSD node
  CPU: Core i7 X980 (12 threads)
  MB: ASUS P6X58D Premium(Intel X58)
  NIC1: Intel Gigabit ET Dual Port Server Adapter(82576)
  NIC2: Intel Ethernet X520-DA2 Server Adapter(82599)
 - Linux node
  CPU: Core 2 Quad (4 threads)
  MB: GIGABYTE GA-G33-DS3R(Intel G33)
  NIC1: Intel Gigabit ET Dual Port Server Adapter(82576)
  NIC2: Intel Ethernet X520-DA2 Server Adapter(82599)

 iperf used for generate network traffic, with following argument options
  - Linux node: iperf -c [IP] -i 10 -t 10 -P12
  - FreeBSD node: iperf -s
  # 12 threads, TCP

 following sysctl parameter is changed
  sysctl -w net.bpf.maxbufsize=1048576
>>>
>>>
>>> Thank you for your work! You may want to increase that (4x/8x) and rerun 
>>> the test, though.
>>
>> More, actually. Your current buffer is easily filled.
>
> Hi,
>
> I measured performance again with maxbufsize = 268435456 and multiple
> cpu configurations, here's an result.
> It seems the performance on 10GbE is bit unstable, not scaling
> linearly by adding cpus/queues.
> Maybe it depends some sort of system parameter, but I don't figure out
> the answer.
>
> Multithreaded BPF performance is increasing than single thread BPF in
> all case, anyway.
>
> * Test environment
>  - FreeBSD node
>   CPU: Core i7 X980 (12 threads)
>  # Tested on 1 core, 2 core, 4 core and 6 core configuration (Each
> core has 2 threads using HT)
>   MB: ASUS P6X58D Premium(Intel X58)
>   NIC: Intel Ethernet X520-DA2 Server Adapter(82599)
>
>  - Linux node
>   CPU: Core 2 Quad (4 threads)
>   MB: GIGABYTE GA-G33-DS3R(Intel G33)
>   NIC: Intel Ethernet X520-DA2 Server Adapter(82599)
>
>  - iperf
>   Linux node: iperf -c [IP] -i