jumbo support for bnx(4)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

jumbo support for bnx(4)

David Gwynne-5
ive had this for 2 years or so. updated to current again.

its been tested on the following:

bnx0 at pci4 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
bnx1 at pci13 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
bnx0: address 00:1e:4f:1b:26:53
brgphy0 at bnx0 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
bnx1: address 00:1e:4f:1b:26:51
brgphy1 at bnx1 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6

itd be nice to get tests on other variants.

ok?

Index: if_bnx.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
retrieving revision 1.107
diff -u -p -r1.107 if_bnx.c
--- if_bnx.c 18 Jul 2014 07:11:04 -0000 1.107
+++ if_bnx.c 13 Aug 2014 10:40:24 -0000
@@ -848,6 +848,8 @@ bnx_attachhook(void *xsc)
  sc->bnx_rx_ticks               = 18;
 #endif
 
+ sc->mbuf_alloc_size = BNX_MAX_JUMBO_MRU;
+
  /* Update statistics once every second. */
  sc->bnx_stats_ticks = 1000000 & 0xffff00;
 
@@ -878,6 +880,7 @@ bnx_attachhook(void *xsc)
  ifp->if_ioctl = bnx_ioctl;
  ifp->if_start = bnx_start;
  ifp->if_watchdog = bnx_watchdog;
+ ifp->if_hardmtu = BNX_MAX_JUMBO_MTU;
  IFQ_SET_MAXLEN(&ifp->if_snd, USABLE_TX_BD - 1);
  IFQ_SET_READY(&ifp->if_snd);
  bcopy(sc->eaddr, sc->arpcom.ac_enaddr, ETHER_ADDR_LEN);
@@ -890,8 +893,6 @@ bnx_attachhook(void *xsc)
  ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING;
 #endif
 
- sc->mbuf_alloc_size = BNX_MAX_MRU;
-
  printf("%s: address %s\n", sc->bnx_dev.dv_xname,
     ether_sprintf(sc->arpcom.ac_enaddr));
 
@@ -2647,8 +2648,8 @@ bnx_dma_alloc(struct bnx_softc *sc)
  * Create DMA maps for the Rx buffer mbufs.
  */
  for (i = 0; i < TOTAL_RX_BD; i++) {
- if (bus_dmamap_create(sc->bnx_dmatag, BNX_MAX_MRU,
-    BNX_MAX_SEGMENTS, BNX_MAX_MRU, 0, BUS_DMA_NOWAIT,
+ if (bus_dmamap_create(sc->bnx_dmatag, sc->mbuf_alloc_size,
+    1, sc->mbuf_alloc_size, 0, BUS_DMA_NOWAIT,
     &sc->rx_mbuf_map[i])) {
  printf(": Could not create Rx mbuf %d DMA map!\n", i);
  rc = ENOMEM;
@@ -3663,10 +3664,10 @@ bnx_get_buf(struct bnx_softc *sc, u_int1
     *prod_bseq);
 
  /* This is a new mbuf allocation. */
- m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
+ m = MCLGETI(NULL, M_DONTWAIT, NULL, sc->mbuf_alloc_size);
  if (!m)
  return (0);
- m->m_len = m->m_pkthdr.len = MCLBYTES;
+ m->m_len = m->m_pkthdr.len = sc->mbuf_alloc_size;
  /* the chip aligns the ip header for us, no need to m_adj */
 
  /* Map the mbuf cluster into device memory. */
@@ -3979,6 +3980,16 @@ bnx_init_rx_context(struct bnx_softc *sc
  REG_WR(sc, BNX_MQ_MAP_L2_5, val | BNX_MQ_MAP_L2_5_ARM);
  }
 
+ CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, 0);
+
+ /* Configure the rx_bd and page chain mbuf cluster size. */
+ val = (sc->mbuf_alloc_size << 16);
+ CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, val);
+
+ /* Configure the context reserved for jumbo support. */
+ CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_RBDC_KEY,
+    BNX_L2CTX_RX_RBDC_JUMBO_KEY);
+
  /* Point the hardware to the first page in the chain. */
  val = (u_int32_t)((u_int64_t)sc->rx_bd_chain_paddr[0] >> 32);
  CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_NX_BDHADDR_HI, val);
@@ -4746,7 +4757,7 @@ bnx_init(void *xsc)
  bnx_set_mac_addr(sc);
 
  /* Calculate and program the Ethernet MRU size. */
- ether_mtu = BNX_MAX_STD_ETHER_MTU_VLAN;
+ ether_mtu = BNX_MAX_JUMBO_ETHER_MTU;
 
  DBPRINT(sc, BNX_INFO, "%s(): setting MRU = %d\n",
     __FUNCTION__, ether_mtu);
@@ -5134,7 +5145,7 @@ bnx_ioctl(struct ifnet *ifp, u_long comm
 
  case SIOCGIFRXR:
  error = if_rxr_ioctl((struct if_rxrinfo *)ifr->ifr_data,
-    NULL, MCLBYTES, &sc->rx_ring);
+    NULL, sc->mbuf_alloc_size, &sc->rx_ring);
  break;
 
  default:

Reply | Threaded
Open this post in threaded view
|

Re: jumbo support for bnx(4)

David Gwynne-5
the silence is deafening.

unless anyone objects im going to commit this tomorrow (~8pm GMT+10) to force some testing.

dlg

On 13 Aug 2014, at 8:42 pm, David Gwynne <[hidden email]> wrote:

> ive had this for 2 years or so. updated to current again.
>
> its been tested on the following:
>
> bnx0 at pci4 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
> bnx1 at pci13 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
> bnx0: address 00:1e:4f:1b:26:53
> brgphy0 at bnx0 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
> bnx1: address 00:1e:4f:1b:26:51
> brgphy1 at bnx1 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
>
> itd be nice to get tests on other variants.
>
> ok?
>
> Index: if_bnx.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
> retrieving revision 1.107
> diff -u -p -r1.107 if_bnx.c
> --- if_bnx.c 18 Jul 2014 07:11:04 -0000 1.107
> +++ if_bnx.c 13 Aug 2014 10:40:24 -0000
> @@ -848,6 +848,8 @@ bnx_attachhook(void *xsc)
> sc->bnx_rx_ticks               = 18;
> #endif
>
> + sc->mbuf_alloc_size = BNX_MAX_JUMBO_MRU;
> +
> /* Update statistics once every second. */
> sc->bnx_stats_ticks = 1000000 & 0xffff00;
>
> @@ -878,6 +880,7 @@ bnx_attachhook(void *xsc)
> ifp->if_ioctl = bnx_ioctl;
> ifp->if_start = bnx_start;
> ifp->if_watchdog = bnx_watchdog;
> + ifp->if_hardmtu = BNX_MAX_JUMBO_MTU;
> IFQ_SET_MAXLEN(&ifp->if_snd, USABLE_TX_BD - 1);
> IFQ_SET_READY(&ifp->if_snd);
> bcopy(sc->eaddr, sc->arpcom.ac_enaddr, ETHER_ADDR_LEN);
> @@ -890,8 +893,6 @@ bnx_attachhook(void *xsc)
> ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING;
> #endif
>
> - sc->mbuf_alloc_size = BNX_MAX_MRU;
> -
> printf("%s: address %s\n", sc->bnx_dev.dv_xname,
>    ether_sprintf(sc->arpcom.ac_enaddr));
>
> @@ -2647,8 +2648,8 @@ bnx_dma_alloc(struct bnx_softc *sc)
> * Create DMA maps for the Rx buffer mbufs.
> */
> for (i = 0; i < TOTAL_RX_BD; i++) {
> - if (bus_dmamap_create(sc->bnx_dmatag, BNX_MAX_MRU,
> -    BNX_MAX_SEGMENTS, BNX_MAX_MRU, 0, BUS_DMA_NOWAIT,
> + if (bus_dmamap_create(sc->bnx_dmatag, sc->mbuf_alloc_size,
> +    1, sc->mbuf_alloc_size, 0, BUS_DMA_NOWAIT,
>    &sc->rx_mbuf_map[i])) {
> printf(": Could not create Rx mbuf %d DMA map!\n", i);
> rc = ENOMEM;
> @@ -3663,10 +3664,10 @@ bnx_get_buf(struct bnx_softc *sc, u_int1
>    *prod_bseq);
>
> /* This is a new mbuf allocation. */
> - m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
> + m = MCLGETI(NULL, M_DONTWAIT, NULL, sc->mbuf_alloc_size);
> if (!m)
> return (0);
> - m->m_len = m->m_pkthdr.len = MCLBYTES;
> + m->m_len = m->m_pkthdr.len = sc->mbuf_alloc_size;
> /* the chip aligns the ip header for us, no need to m_adj */
>
> /* Map the mbuf cluster into device memory. */
> @@ -3979,6 +3980,16 @@ bnx_init_rx_context(struct bnx_softc *sc
> REG_WR(sc, BNX_MQ_MAP_L2_5, val | BNX_MQ_MAP_L2_5_ARM);
> }
>
> + CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, 0);
> +
> + /* Configure the rx_bd and page chain mbuf cluster size. */
> + val = (sc->mbuf_alloc_size << 16);
> + CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, val);
> +
> + /* Configure the context reserved for jumbo support. */
> + CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_RBDC_KEY,
> +    BNX_L2CTX_RX_RBDC_JUMBO_KEY);
> +
> /* Point the hardware to the first page in the chain. */
> val = (u_int32_t)((u_int64_t)sc->rx_bd_chain_paddr[0] >> 32);
> CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_NX_BDHADDR_HI, val);
> @@ -4746,7 +4757,7 @@ bnx_init(void *xsc)
> bnx_set_mac_addr(sc);
>
> /* Calculate and program the Ethernet MRU size. */
> - ether_mtu = BNX_MAX_STD_ETHER_MTU_VLAN;
> + ether_mtu = BNX_MAX_JUMBO_ETHER_MTU;
>
> DBPRINT(sc, BNX_INFO, "%s(): setting MRU = %d\n",
>    __FUNCTION__, ether_mtu);
> @@ -5134,7 +5145,7 @@ bnx_ioctl(struct ifnet *ifp, u_long comm
>
> case SIOCGIFRXR:
> error = if_rxr_ioctl((struct if_rxrinfo *)ifr->ifr_data,
> -    NULL, MCLBYTES, &sc->rx_ring);
> +    NULL, sc->mbuf_alloc_size, &sc->rx_ring);
> break;
>
> default:


Reply | Threaded
Open this post in threaded view
|

Re: jumbo support for bnx(4)

Brad Smith-14
In reply to this post by David Gwynne-5
On 13/08/14 6:42 AM, David Gwynne wrote:

> ive had this for 2 years or so. updated to current again.
>
> its been tested on the following:
>
> bnx0 at pci4 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
> bnx1 at pci13 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
> bnx0: address 00:1e:4f:1b:26:53
> brgphy0 at bnx0 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
> bnx1: address 00:1e:4f:1b:26:51
> brgphy1 at bnx1 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
>
> itd be nice to get tests on other variants.
>
> ok?

This is exactly the same diff that was posted in the past
and it wouldn't be any less broken on the BCM5709 chipsets
now.

> Index: if_bnx.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
> retrieving revision 1.107
> diff -u -p -r1.107 if_bnx.c
> --- if_bnx.c 18 Jul 2014 07:11:04 -0000 1.107
> +++ if_bnx.c 13 Aug 2014 10:40:24 -0000
> @@ -848,6 +848,8 @@ bnx_attachhook(void *xsc)
>   sc->bnx_rx_ticks               = 18;
>   #endif
>
> + sc->mbuf_alloc_size = BNX_MAX_JUMBO_MRU;
> +
>   /* Update statistics once every second. */
>   sc->bnx_stats_ticks = 1000000 & 0xffff00;
>
> @@ -878,6 +880,7 @@ bnx_attachhook(void *xsc)
>   ifp->if_ioctl = bnx_ioctl;
>   ifp->if_start = bnx_start;
>   ifp->if_watchdog = bnx_watchdog;
> + ifp->if_hardmtu = BNX_MAX_JUMBO_MTU;
>   IFQ_SET_MAXLEN(&ifp->if_snd, USABLE_TX_BD - 1);
>   IFQ_SET_READY(&ifp->if_snd);
>   bcopy(sc->eaddr, sc->arpcom.ac_enaddr, ETHER_ADDR_LEN);
> @@ -890,8 +893,6 @@ bnx_attachhook(void *xsc)
>   ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING;
>   #endif
>
> - sc->mbuf_alloc_size = BNX_MAX_MRU;
> -
>   printf("%s: address %s\n", sc->bnx_dev.dv_xname,
>      ether_sprintf(sc->arpcom.ac_enaddr));
>
> @@ -2647,8 +2648,8 @@ bnx_dma_alloc(struct bnx_softc *sc)
>   * Create DMA maps for the Rx buffer mbufs.
>   */
>   for (i = 0; i < TOTAL_RX_BD; i++) {
> - if (bus_dmamap_create(sc->bnx_dmatag, BNX_MAX_MRU,
> -    BNX_MAX_SEGMENTS, BNX_MAX_MRU, 0, BUS_DMA_NOWAIT,
> + if (bus_dmamap_create(sc->bnx_dmatag, sc->mbuf_alloc_size,
> +    1, sc->mbuf_alloc_size, 0, BUS_DMA_NOWAIT,
>      &sc->rx_mbuf_map[i])) {
>   printf(": Could not create Rx mbuf %d DMA map!\n", i);
>   rc = ENOMEM;
> @@ -3663,10 +3664,10 @@ bnx_get_buf(struct bnx_softc *sc, u_int1
>      *prod_bseq);
>
>   /* This is a new mbuf allocation. */
> - m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
> + m = MCLGETI(NULL, M_DONTWAIT, NULL, sc->mbuf_alloc_size);
>   if (!m)
>   return (0);
> - m->m_len = m->m_pkthdr.len = MCLBYTES;
> + m->m_len = m->m_pkthdr.len = sc->mbuf_alloc_size;
>   /* the chip aligns the ip header for us, no need to m_adj */
>
>   /* Map the mbuf cluster into device memory. */
> @@ -3979,6 +3980,16 @@ bnx_init_rx_context(struct bnx_softc *sc
>   REG_WR(sc, BNX_MQ_MAP_L2_5, val | BNX_MQ_MAP_L2_5_ARM);
>   }
>
> + CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, 0);
> +
> + /* Configure the rx_bd and page chain mbuf cluster size. */
> + val = (sc->mbuf_alloc_size << 16);
> + CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, val);
> +
> + /* Configure the context reserved for jumbo support. */
> + CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_RBDC_KEY,
> +    BNX_L2CTX_RX_RBDC_JUMBO_KEY);
> +
>   /* Point the hardware to the first page in the chain. */
>   val = (u_int32_t)((u_int64_t)sc->rx_bd_chain_paddr[0] >> 32);
>   CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_NX_BDHADDR_HI, val);
> @@ -4746,7 +4757,7 @@ bnx_init(void *xsc)
>   bnx_set_mac_addr(sc);
>
>   /* Calculate and program the Ethernet MRU size. */
> - ether_mtu = BNX_MAX_STD_ETHER_MTU_VLAN;
> + ether_mtu = BNX_MAX_JUMBO_ETHER_MTU;
>
>   DBPRINT(sc, BNX_INFO, "%s(): setting MRU = %d\n",
>      __FUNCTION__, ether_mtu);
> @@ -5134,7 +5145,7 @@ bnx_ioctl(struct ifnet *ifp, u_long comm
>
>   case SIOCGIFRXR:
>   error = if_rxr_ioctl((struct if_rxrinfo *)ifr->ifr_data,
> -    NULL, MCLBYTES, &sc->rx_ring);
> +    NULL, sc->mbuf_alloc_size, &sc->rx_ring);
>   break;
>
>   default:
>
>


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Reply | Threaded
Open this post in threaded view
|

Re: jumbo support for bnx(4)

Stuart Henderson-6
On 2014/08/14 17:09, Brad Smith wrote:

> On 13/08/14 6:42 AM, David Gwynne wrote:
> >ive had this for 2 years or so. updated to current again.
> >
> >its been tested on the following:
> >
> >bnx0 at pci4 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
> >bnx1 at pci13 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
> >bnx0: address 00:1e:4f:1b:26:53
> >brgphy0 at bnx0 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
> >bnx1: address 00:1e:4f:1b:26:51
> >brgphy1 at bnx1 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
> >
> >itd be nice to get tests on other variants.
> >
> >ok?
>
> This is exactly the same diff that was posted in the past
> and it wouldn't be any less broken on the BCM5709 chipsets
> now.

Trying it on dual BCM5709 with 1500 MTU (not in a position to test jumbos
there at present). One interface has vlans on, that seems OK. Another has
pppoe(4) and an IP address on it to reach the router; this suffers high
packet loss, similar to what I remember happening with BCM5716 in
http://thread.gmane.org/gmane.os.openbsd.misc/195644/focus=195677

Reply | Threaded
Open this post in threaded view
|

Re: jumbo support for bnx(4)

Stuart Henderson-6
On 2014/08/14 22:38, Stuart Henderson wrote:

> On 2014/08/14 17:09, Brad Smith wrote:
> > On 13/08/14 6:42 AM, David Gwynne wrote:
> > >ive had this for 2 years or so. updated to current again.
> > >
> > >its been tested on the following:
> > >
> > >bnx0 at pci4 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
> > >bnx1 at pci13 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
> > >bnx0: address 00:1e:4f:1b:26:53
> > >brgphy0 at bnx0 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
> > >bnx1: address 00:1e:4f:1b:26:51
> > >brgphy1 at bnx1 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
> > >
> > >itd be nice to get tests on other variants.
> > >
> > >ok?
> >
> > This is exactly the same diff that was posted in the past
> > and it wouldn't be any less broken on the BCM5709 chipsets
> > now.
>
> Trying it on dual BCM5709 with 1500 MTU (not in a position to test jumbos
> there at present). One interface has vlans on, that seems OK. Another has
> pppoe(4) and an IP address on it to reach the router; this suffers high
> packet loss, similar to what I remember happening with BCM5716 in
> http://thread.gmane.org/gmane.os.openbsd.misc/195644/focus=195677
>

btw, BCM5716 can be found on R210 and R410

Reply | Threaded
Open this post in threaded view
|

Re: jumbo support for bnx(4)

Brad Smith-14
In reply to this post by Brad Smith-14
On 14/08/14 5:09 PM, Brad Smith wrote:

> On 13/08/14 6:42 AM, David Gwynne wrote:
>> ive had this for 2 years or so. updated to current again.
>>
>> its been tested on the following:
>>
>> bnx0 at pci4 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
>> bnx1 at pci13 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
>> bnx0: address 00:1e:4f:1b:26:53
>> brgphy0 at bnx0 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
>> bnx1: address 00:1e:4f:1b:26:51
>> brgphy1 at bnx1 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
>>
>> itd be nice to get tests on other variants.
>>
>> ok?
>
> This is exactly the same diff that was posted in the past
> and it wouldn't be any less broken on the BCM5709 chipsets
> now.

Since someone said I should say what I did in a clearer manner..

Since the diff has not changed and was broken when it was originally
posted then it will still be broken now.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Reply | Threaded
Open this post in threaded view
|

Re: jumbo support for bnx(4)

David Gwynne-5
ok

i have a 5709 somewhere i can work on.

dlg

On 15 Aug 2014, at 9:50 am, Brad Smith <[hidden email]> wrote:

> On 14/08/14 5:09 PM, Brad Smith wrote:
>> On 13/08/14 6:42 AM, David Gwynne wrote:
>>> ive had this for 2 years or so. updated to current again.
>>>
>>> its been tested on the following:
>>>
>>> bnx0 at pci4 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
>>> bnx1 at pci13 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
>>> bnx0: address 00:1e:4f:1b:26:53
>>> brgphy0 at bnx0 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
>>> bnx1: address 00:1e:4f:1b:26:51
>>> brgphy1 at bnx1 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
>>>
>>> itd be nice to get tests on other variants.
>>>
>>> ok?
>>
>> This is exactly the same diff that was posted in the past
>> and it wouldn't be any less broken on the BCM5709 chipsets
>> now.
>
> Since someone said I should say what I did in a clearer manner..
>
> Since the diff has not changed and was broken when it was originally
> posted then it will still be broken now.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.