Re: Which module contains functins(arptimer)?
On 09/07/11 18:06, Gary Palmer wrote: On Wed, Sep 07, 2011 at 04:51:48PM +0400, Vladimir Budnev wrote: Hello. How to determine which module contains specific functinos?. For example we have arptimer in netinet/if_ether.c. But how to find in which ko it compiles? Iv tried ls /boot/kernel/ | grep ko.symbols | xargs strings | grep -i arptimer but that didnt work :( Thanks in advance. arptimer is declared static so I doubt it will show up in linker symbol tables or via "strings". Also AFAIK we don't support loading TCP/IP as a module so its probably only compiled into the kernel itself and not available as a module. Gary Ok, roger that. Thank you for answers ___ 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: Adding Flow Director sysctls to ixgbe(4)
Hi, 2011/9/5 Ben Hutchings : > On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: >> Hi, >> >> I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: >> >> - Adding removing signature filter >> On linux version of ixgbe driver, it has ability to set/remove perfect >> filter from userland using ethtool command. >> I implemented similar feature, but on sysctl, and not perfect filter >> but signature filter(which means hash collision may occurs). > [...] > > Linux also has a generic interface to RX filtering and hashing > (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > to support something like that? > > Ben. Linux implement it on ethtool command, what should we do? Maybe a new option for ifconfig, or provide new command for it? ___ 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: Adding Flow Director sysctls to ixgbe(4)
On Sep 8, 2011, at 10:11 AM, Takuya ASADA wrote: > Hi, > > 2011/9/5 Ben Hutchings : >> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: >>> Hi, >>> >>> I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: >>> >>> - Adding removing signature filter >>> On linux version of ixgbe driver, it has ability to set/remove perfect >>> filter from userland using ethtool command. >>> I implemented similar feature, but on sysctl, and not perfect filter >>> but signature filter(which means hash collision may occurs). >> [...] >> >> Linux also has a generic interface to RX filtering and hashing >> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD >> to support something like that? >> >> Ben. > > Linux implement it on ethtool command, what should we do? > Maybe a new option for ifconfig, or provide new command for it? I for one would love to see this functionality built into ifconfig. Linux always seems to have one tool too many. There's ifconfig, iproute2, route, mii-tool and ethtool. ___ 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: Adding Flow Director sysctls to ixgbe(4)
On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > > Hi, > > > > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > > > > - Adding removing signature filter > > On linux version of ixgbe driver, it has ability to set/remove perfect > > filter from userland using ethtool command. > > I implemented similar feature, but on sysctl, and not perfect filter > > but signature filter(which means hash collision may occurs). > [...] > > Linux also has a generic interface to RX filtering and hashing > (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > to support something like that? Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) drivers both provide their own tools to manipulate filters, though they do not provide explicit steering IIRC. We would need to come up with some sort of standard interface (ioctls?) for adding filters however. -- John Baldwin ___ 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: Adding Flow Director sysctls to ixgbe(4)
On Thu, 2011-09-08 at 08:34 -0400, John Baldwin wrote: > On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > > On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > > > Hi, > > > > > > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > > > > > > - Adding removing signature filter > > > On linux version of ixgbe driver, it has ability to set/remove perfect > > > filter from userland using ethtool command. > > > I implemented similar feature, but on sysctl, and not perfect filter > > > but signature filter(which means hash collision may occurs). > > [...] > > > > Linux also has a generic interface to RX filtering and hashing > > (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > > to support something like that? > > Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) drivers > both provide their own tools to manipulate filters, though they do not > provide explicit steering IIRC. > > We would need to come up with some sort of standard interface (ioctls?) for > adding filters however. On Linux, filtering and steering are supported on the Freescale TSEC/FEC (gianfar), Intel Niantic (ixgbe), Solarflare (sfc) and Sun Neptune (niu) hardware. The exact capabilities of the hardware are all quite different and we're still recovering from the early mistake of defining two subtly different interfaces. I believe several other 10G Ethernet vendors have implemented these sorts of hardware capabilities. 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: Adding Flow Director sysctls to ixgbe(4)
On Thu, 2011-09-08 at 10:55 +0200, Vlad Galu wrote: > On Sep 8, 2011, at 10:11 AM, Takuya ASADA wrote: > > Hi, > > > > 2011/9/5 Ben Hutchings : > >> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > >>> Hi, > >>> > >>> I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > >>> > >>> - Adding removing signature filter > >>> On linux version of ixgbe driver, it has ability to set/remove perfect > >>> filter from userland using ethtool command. > >>> I implemented similar feature, but on sysctl, and not perfect filter > >>> but signature filter(which means hash collision may occurs). > >> [...] > >> > >> Linux also has a generic interface to RX filtering and hashing > >> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > >> to support something like that? > >> > >> Ben. > > > > Linux implement it on ethtool command, what should we do? > > Maybe a new option for ifconfig, or provide new command for it? > > I for one would love to see this functionality built into ifconfig. > Linux always seems to have one tool too many. There's ifconfig, > iproute2, route, mii-tool and ethtool. The current tools are iproute2 (replacing ifconfig and route) and ethtool. mii-tool might still be useful for debugging a 10M or 100M driver, but ethtool can display anything an administrator would be interested in. Now you could quite reasonably say that the improvements made in iproute2 ought to have been done without creating a new command. But it is not true that all these different commands are required. 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: Adding Flow Director sysctls to ixgbe(4)
On Sep 8, 2011, at 4:35 PM, Ben Hutchings wrote: > On Thu, 2011-09-08 at 10:55 +0200, Vlad Galu wrote: >> On Sep 8, 2011, at 10:11 AM, Takuya ASADA wrote: >>> Hi, >>> >>> 2011/9/5 Ben Hutchings : On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: [...] Linux also has a generic interface to RX filtering and hashing (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD to support something like that? Ben. >>> >>> Linux implement it on ethtool command, what should we do? >>> Maybe a new option for ifconfig, or provide new command for it? >> >> I for one would love to see this functionality built into ifconfig. >> Linux always seems to have one tool too many. There's ifconfig, >> iproute2, route, mii-tool and ethtool. > > The current tools are iproute2 (replacing ifconfig and route) and > ethtool. mii-tool might still be useful for debugging a 10M or 100M > driver, but ethtool can display anything an administrator would be > interested in. > > Now you could quite reasonably say that the improvements made in > iproute2 ought to have been done without creating a new command. But it > is not true that all these different commands are required. > > Ben. You're right, I didn't mean that, only that, sometimes, diversity isn't necessarily a good thing. ___ 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: Adding Flow Director sysctls to ixgbe(4)
On Thu, Sep 8, 2011 at 2:34 PM, John Baldwin wrote: > On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: >> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: >> > Hi, >> > >> > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: >> > >> > - Adding removing signature filter >> > On linux version of ixgbe driver, it has ability to set/remove perfect >> > filter from userland using ethtool command. >> > I implemented similar feature, but on sysctl, and not perfect filter >> > but signature filter(which means hash collision may occurs). >> [...] >> >> Linux also has a generic interface to RX filtering and hashing >> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD >> to support something like that? > > Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) drivers > both provide their own tools to manipulate filters, though they do not > provide explicit steering IIRC. > > We would need to come up with some sort of standard interface (ioctls?) for > adding filters however. I know this must sound like nitpicking, but please don't add more ioctls if you can avoid it. If you want to add new interfaces try to stick with sysctl as it tends to be less prone to breakage across releases. The biggest problem in defining a new API is the lack of anyone with a global overview of the functionality provided by NIC vendors and their near-term roadmaps. It doesn't make sense to add an API that we only know works for one or two vendors. Cheers ___ 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: Adding Flow Director sysctls to ixgbe(4)
On Thursday, September 08, 2011 10:48:25 am K. Macy wrote: > On Thu, Sep 8, 2011 at 2:34 PM, John Baldwin wrote: > > On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > >> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > >> > Hi, > >> > > >> > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a > >> > detail: > >> > > >> > - Adding removing signature filter > >> > On linux version of ixgbe driver, it has ability to set/remove perfect > >> > filter from userland using ethtool command. > >> > I implemented similar feature, but on sysctl, and not perfect filter > >> > but signature filter(which means hash collision may occurs). > >> [...] > >> > >> Linux also has a generic interface to RX filtering and hashing > >> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > >> to support something like that? > > > > Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) > > drivers > > both provide their own tools to manipulate filters, though they do not > > provide explicit steering IIRC. > > > > We would need to come up with some sort of standard interface (ioctls?) for > > adding filters however. > > I know this must sound like nitpicking, but please don't add more > ioctls if you can avoid it. If you want to add new interfaces try to > stick with sysctl as it tends to be less prone to breakage across > releases. Passing strings in via sysctls isn't an ideal interface. Passing in some sort of structure via ioctl would be far more typical, and it is possible to provide API compat since the size of the structure is encoded in the ioctl itself. -- John Baldwin ___ 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: Adding Flow Director sysctls to ixgbe(4)
On Thu, 2011-09-08 at 11:06 -0400, John Baldwin wrote: > On Thursday, September 08, 2011 10:48:25 am K. Macy wrote: > > On Thu, Sep 8, 2011 at 2:34 PM, John Baldwin wrote: > > > On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > > >> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > > >> > Hi, > > >> > > > >> > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a > > >> > detail: > > >> > > > >> > - Adding removing signature filter > > >> > On linux version of ixgbe driver, it has ability to set/remove perfect > > >> > filter from userland using ethtool command. > > >> > I implemented similar feature, but on sysctl, and not perfect filter > > >> > but signature filter(which means hash collision may occurs). > > >> [...] > > >> > > >> Linux also has a generic interface to RX filtering and hashing > > >> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > > >> to support something like that? > > > > > > Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) > > > drivers > > > both provide their own tools to manipulate filters, though they do not > > > provide explicit steering IIRC. > > > > > > We would need to come up with some sort of standard interface (ioctls?) > > > for > > > adding filters however. > > > > I know this must sound like nitpicking, but please don't add more > > ioctls if you can avoid it. If you want to add new interfaces try to > > stick with sysctl as it tends to be less prone to breakage across > > releases. > > Passing strings in via sysctls isn't an ideal interface. Passing in some sort > of structure via ioctl would be far more typical, and it is possible to > provide > API compat since the size of the structure is encoded in the ioctl itself. Whatever the mechanism is, the interface should allow for: - Flexible matching on layer 2, 3 and 4 header fields - Masking out some bits before matching (e.g. ignoring priority bits of VLAN tag or least significant bits of IPv4 address) - Priority of rules in case several match a single flow. This may need to be combined with location, since in a TCAM location may determine priority. - Requesting packets to be dropped, steered to a single RX queue, or steered to a range of RX queues (using a flow hash and indirection table) - Use of multiple hash indirection tables 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: Adding Flow Director sysctls to ixgbe(4)
> Whatever the mechanism is, the interface should allow for: > > - Flexible matching on layer 2, 3 and 4 header fields > - Masking out some bits before matching (e.g. ignoring priority bits of > VLAN tag or least significant bits of IPv4 address) > - Priority of rules in case several match a single flow. This may > need to be combined with location, since in a TCAM location may > determine priority. > - Requesting packets to be dropped, steered to a single RX queue, or > steered to a range of RX queues (using a flow hash and indirection > table) > - Use of multiple hash indirection tables Do you feel that the Linux API for this is the right place to start looking? Earlier you said: "The exact capabilities of the hardware are all quite different and we're still recovering from the early mistake of defining two subtly different interfaces." Have the two APIs been unified, if not which one do you believe is the "right" one? Cheers ___ 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: Adding Flow Director sysctls to ixgbe(4)
On Thu, 2011-09-08 at 18:28 +0200, K. Macy wrote: > > Whatever the mechanism is, the interface should allow for: > > > > - Flexible matching on layer 2, 3 and 4 header fields > > - Masking out some bits before matching (e.g. ignoring priority bits of > > VLAN tag or least significant bits of IPv4 address) > > - Priority of rules in case several match a single flow. This may > > need to be combined with location, since in a TCAM location may > > determine priority. > > - Requesting packets to be dropped, steered to a single RX queue, or > > steered to a range of RX queues (using a flow hash and indirection > > table) > > - Use of multiple hash indirection tables > > Do you feel that the Linux API for this is the right place to start > looking? You can certainly learn from the mistakes made in Linux. :-) > Earlier you said: "The exact capabilities of the hardware > are all quite > different and we're still recovering from the early mistake of > defining two subtly different interfaces." Have the two APIs been > unified, if not which one do you believe is the "right" one? RX NFC is the right one. The other one (RX n-tuple) will be removed once I've converted the sfc driver to use RX NFC. It isn't flexible enough to cover the full matching capabilities and it doesn't allow for requesting steering + hashing, although I'm hoping to extend it to cover that later. 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: Adding Flow Director sysctls to ixgbe(4)
On Thu, Sep 08, 2011 at 08:34:11AM -0400, John Baldwin wrote: > On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > > On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > > > Hi, > > > > > > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > > > > > > - Adding removing signature filter > > > On linux version of ixgbe driver, it has ability to set/remove perfect > > > filter from userland using ethtool command. > > > I implemented similar feature, but on sysctl, and not perfect filter > > > but signature filter(which means hash collision may occurs). > > [...] > > > > Linux also has a generic interface to RX filtering and hashing > > (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > > to support something like that? > > Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) drivers > both provide their own tools to manipulate filters, though they do not > provide explicit steering IIRC. Both of them can filter as well as steer (and the tools let you do that). cxgbe(4) can do a lot more (rewrite + switch, replicate, etc.) but those features are perhaps too specialized to be configurable via a general purpose tool. > > We would need to come up with some sort of standard interface (ioctls?) for > adding filters however. +1 for a standard interface. imho the kernel needs to be aware of the rx and tx queues of a NIC, and not just for steering. But that's a separate discussion. Regards, Navdeep ___ 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: FreeBSD 7-STABLE mbuf corruption
Hi,
On Wed, Sep 7, 2011 at 8:18 PM, Sean Bruno wrote:
> [...]
> In addition to some txeof() handling patches ... Jack can see if this is
> still relevant in the freebsd7 universe. Note that Yahoo is "special"
> and we pluck and chuck code/drivers/whatever at will so I don't know how
> this code will apply to stable-7 or if it has been applied already.
>
> Note that this code "rage-quits" the EIAM/EIAC auto ack strategy and
> tries to handle the OACTIVE state handling better. I hope these clues
> find you well.
>
Just for the record, I'll comment inline.
> --- //depot/yahoo/ybsd_7/src/sys/dev/e1000/if_igb.c 2010-11-29
> 20:47:23.0
> +++ /home/seanbru/ybsd_7/src/sys/dev/e1000/if_igb.c 2010-11-29
> 20:47:23.0
> @@ -30,7 +30,7 @@
> POSSIBILITY OF SUCH DAMAGE.
>
>
> **/
> -/*$FreeBSD: src/sys/dev/e1000/if_igb.c,v 1.3.2.13 2010/11/27 01:09:54
> jfv Exp $*/
> +/*$FreeBSD: stable/7/sys/dev/e1000/if_igb.c 216465 2010-12-15 22:48:44Z
> jfv $*/
>
>
> #ifdef HAVE_KERNEL_OPTION_HEADERS
> @@ -318,10 +318,6 @@
> static bool igb_header_split = FALSE;
> TUNABLE_INT("hw.igb.hdr_split", &igb_header_split);
>
> -/*
> -** This will autoconfigure based on
> -** the number of CPUs if left at 0.
> -*/
> static int igb_num_queues = 0;
> TUNABLE_INT("hw.igb.num_queues", &igb_num_queues);
>
> @@ -784,10 +780,14 @@
> return;
>
> /* Call cleanup if number of TX descriptors low */
> +#if 0
> if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD)
> igb_txeof(txr);
> +#endif
>
> while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
> + if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD)
> + igb_txeof(txr);
> if (txr->tx_avail <= IGB_TX_OP_THRESHOLD) {
> ifp->if_drv_flags |= IFF_DRV_OACTIVE;
> break;
> @@ -1162,10 +1162,10 @@
> IGB_TX_LOCK(txr);
> if (igb_txeof(txr))
> more = TRUE;
> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
> - igb_start_locked(txr, ifp);
> + /*if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) Pointless as
> igb_start_locked() checks this right off the bat*/
> + igb_start_locked(txr, ifp);
> IGB_TX_UNLOCK(txr);
> - if (more) {
> + if (more || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
> taskqueue_enqueue(que->tq, &que->que_task);
> return;
> }
that hunk seem already to be in the HEAD driver.
> @@ -1298,15 +1298,20 @@
> struct rx_ring *rxr = que->rxr;
> u32 newitr = 0;
> bool more_tx, more_rx;
> + struct ifnet *ifp = adapter->ifp;
>
> +#if 0
> E1000_WRITE_REG(&adapter->hw, E1000_EIMC, que->eims);
> + newitr = E1000_READ_REG(&adapter->hw, E1000_EICR);
> +#endif
> + E1000_WRITE_REG(&adapter->hw, E1000_EICR, que->eims);
> ++que->irqs;
>
> IGB_TX_LOCK(txr);
> more_tx = igb_txeof(txr);
> IGB_TX_UNLOCK(txr);
>
already in HEAD.
> - more_rx = igb_rxeof(que, adapter->rx_process_limit, NULL);
> + more_rx = igb_rxeof(que, -1, NULL);
>
> if (igb_enable_aim == FALSE)
> goto no_calc;
applied manually.
> @@ -1361,7 +1366,7 @@
>
> no_calc:
> /* Schedule a clean task if needed*/
> - if (more_tx || more_rx)
> + if (more_tx || more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE))
> taskqueue_enqueue(que->tq, &que->que_task);
> else
> /* Reenable this interrupt */
already in HEAD.
> @@ -1382,6 +1387,7 @@
> struct adapter *adapter = arg;
> u32 icr;
>
> + E1000_WRITE_REG(&adapter->hw, E1000_EICR, adapter->link_mask);
> ++adapter->link_irq;
> icr = E1000_READ_REG(&adapter->hw, E1000_ICR);
> if (!(icr & E1000_ICR_LSC))
applied manually.
> @@ -1535,6 +1541,14 @@
> if (m_head->m_flags & M_VLANTAG)
> cmd_type_len |= E1000_ADVTXD_DCMD_VLE;
>
> +/*
> + * We just did this in before invocation, seems completely
> + * redundant, igb_handle_queue -> igb_txeof
> + * Pretty sure this is impossible as we check for the
> + * IGB_TX_CLEANUP_THRESHOLD in igb_start_locked() which happens
> + * before this func in invoked
> + */
> +#if 0
> /*
> * Force a cleanup if number of TX descriptors
> * available hits the threshold
> @@ -1547,6 +1561,7 @@
> return (ENOBUFS);
> }
> }
> +#endif
>
> /*
> * Map the packet for DMA.
already in HEAD.
> @@ -2082,6 +2097,7 @@
> que->eims = E1000_EICR_TX_QUEUE0 << i;
> else
> que->eims = 1 << vector;
> + device_printf(adapter->dev, "que %d eims= 0x%x\n", i,
> que->eims)
Re: Adding Flow Director sysctls to ixgbe(4)
On Sep 8, 2011, at 14:49 , Navdeep Parhar wrote: > On Thu, Sep 08, 2011 at 08:34:11AM -0400, John Baldwin wrote: >> On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: >>> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: Hi, I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: - Adding removing signature filter On linux version of ixgbe driver, it has ability to set/remove perfect filter from userland using ethtool command. I implemented similar feature, but on sysctl, and not perfect filter but signature filter(which means hash collision may occurs). >>> [...] >>> >>> Linux also has a generic interface to RX filtering and hashing >>> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD >>> to support something like that? >> >> Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) >> drivers >> both provide their own tools to manipulate filters, though they do not >> provide explicit steering IIRC. > > Both of them can filter as well as steer (and the tools let you do that). > cxgbe(4) can do a lot more (rewrite + switch, replicate, etc.) but those > features are perhaps too specialized to be configurable via a general > purpose tool. > >> >> We would need to come up with some sort of standard interface (ioctls?) for >> adding filters however. > > +1 for a standard interface. > > imho the kernel needs to be aware of the rx and tx queues of a NIC, and > not just for steering. But that's a separate discussion. > Well I do think this is actually all of a part. Most of us realize by now that high speed (e.g. 10G and higher) NICs only make sense if you can steer traffic and pin queues to cores etc. Without those pieces in place it's impossible to get the full utilization out of the NIC because things like cache misses just kill your performance. Having looked at a few 10G NICs in the last couple of years the one thing I notice is that everyone wants to do things like offload and steering but that the specifics are quite different between different cards. Some of that has to do with the libraries that expose these things to the kernel and user programs, but some has to do with how the device is modeled. What this means is that we have a failure of abstraction. Abstraction has a cost, and some of the people who want access to low level queues are not interested in paying an extra abstraction cost. I think that some of the abstractions we need are tied up in the work that Takuya did for SoC and some of it is in the work done by Luigi on netmap. I'd go so far as to say that what we should do is try to combine those two pieces of code into a set of low level APIs for programs to interact with high speed NICs. The one thing most people do not talk about is extending our socket API to do two things that I think would be a win for 80% of our users. If a socket, and also a kqueue, could be pinned to a CPU as well as a NIC queue that should improve overall bandwidth for a large number of our users. The API there is definitely an ioctl() and the hard part is doing the tying together. To do this we need to also work out our low level story. Best, George ___ 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
On Aug 19, 2011, at 06: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. > Sorry to be late on this one. http://pcs.sf.net and /usr/ports/net/py-pcs If you have questions on it let me know. I'm the author. Best, George ___ 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: Intel NIC stops working
On Aug 17, 2011, at 04:06 , Johannes wrote: > Hi Sami, > > thanks for the reply. Unfortunately, down/up the interface does not > resolve the problem. > I have to reboot my server in order to use the nic again. > Crazy suggestion. Check the memory on your server using memtest or the like. Those stats you quoted just look very wrong to me, since they numbers are huge for broadcast and multicast. I think something in memory is trashed. Now, it may be a bug in the driver or somewhere else, but check your memory first. Best, George ___ 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: Adding Flow Director sysctls to ixgbe(4)
On Sep 8, 2011, at 10:48 , K. Macy wrote: > On Thu, Sep 8, 2011 at 2:34 PM, John Baldwin wrote: >> On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: >>> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: Hi, I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: - Adding removing signature filter On linux version of ixgbe driver, it has ability to set/remove perfect filter from userland using ethtool command. I implemented similar feature, but on sysctl, and not perfect filter but signature filter(which means hash collision may occurs). >>> [...] >>> >>> Linux also has a generic interface to RX filtering and hashing >>> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD >>> to support something like that? >> >> Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) >> drivers >> both provide their own tools to manipulate filters, though they do not >> provide explicit steering IIRC. >> >> We would need to come up with some sort of standard interface (ioctls?) for >> adding filters however. > > I know this must sound like nitpicking, but please don't add more > ioctls if you can avoid it. If you want to add new interfaces try to > stick with sysctl as it tends to be less prone to breakage across > releases. > > > The biggest problem in defining a new API is the lack of anyone with a > global overview of the functionality provided by NIC vendors and their > near-term roadmaps. It doesn't make sense to add an API that we only > know works for one or two vendors. > I think this is doable. I've seen enough of these cards to know a bit of what we'd want. This is a subject we've covered in a few different BSDCans but it's probably time for a straw man. I'm not against the sysctl approach but I'll have to give this a bit more thought. The only real options are sockets, ioctls and sysctls, that I can see. Best, George ___ 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
On Aug 19, 2011, at 04:21 , Takuya ASADA wrote: > Any comments or suggestions? > > One comment, one question. First, I think we should try to integrate this work and then tune it up more. The API is, I think, fine, and performance tuning takes a bit of work. Second, what are the parameters set on buffers for the drivers? I.e. how many slots do they have in their queues etc.? If they defaults are too small, and often they are, then that's going to hurt your performance. Best, George ___ 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: Adding Flow Director sysctls to ixgbe(4)
On Thu, 2011-09-08 at 20:13 -0400, George Neville-Neil wrote: > On Sep 8, 2011, at 14:49 , Navdeep Parhar wrote: > > > On Thu, Sep 08, 2011 at 08:34:11AM -0400, John Baldwin wrote: > >> On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > >>> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > Hi, > > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a > detail: > > - Adding removing signature filter > On linux version of ixgbe driver, it has ability to set/remove perfect > filter from userland using ethtool command. > I implemented similar feature, but on sysctl, and not perfect filter > but signature filter(which means hash collision may occurs). > >>> [...] > >>> > >>> Linux also has a generic interface to RX filtering and hashing > >>> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > >>> to support something like that? > >> > >> Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) > >> drivers > >> both provide their own tools to manipulate filters, though they do not > >> provide explicit steering IIRC. > > > > Both of them can filter as well as steer (and the tools let you do that). > > cxgbe(4) can do a lot more (rewrite + switch, replicate, etc.) but those > > features are perhaps too specialized to be configurable via a general > > purpose tool. > > > >> > >> We would need to come up with some sort of standard interface (ioctls?) > >> for > >> adding filters however. > > > > +1 for a standard interface. > > > > imho the kernel needs to be aware of the rx and tx queues of a NIC, and > > not just for steering. But that's a separate discussion. > > > > Well I do think this is actually all of a part. Most of us realize by now > that > high speed (e.g. 10G and higher) NICs only make sense if you can steer > traffic and > pin queues to cores etc. Well, you can get way better than 1G performance without that. And for routers, flow hashing may be fine. But for a host, of course, steering packets properly can provide a major performance win. [...] > What this means is that we have > a failure of abstraction. Abstraction has a cost, and some of the people who > want > access to low level queues are not interested in paying an extra abstraction > cost. Abstraction has a cost, but it's not necessarily that high compared to rewriting a whole chunk of sockets code (especially if you don't actually have the source code). > I think that some of the abstractions we need are tied up in the work that > Takuya did > for SoC and some of it is in the work done by Luigi on netmap. I'd go so far > as to say > that what we should do is try to combine those two pieces of code into a set > of > low level APIs for programs to interact with high speed NICs. The one thing > most > people do not talk about is extending our socket API to do two things that I > think would > be a win for 80% of our users. If a socket, and also a kqueue, could be > pinned > to a CPU as well as a NIC queue that should improve overall bandwidth for a > large > number of our users. The API there is definitely an ioctl() and the hard > part is > doing the tying together. To do this we need to also work out our low level > story. But it would be a lot nicer if this could be done automatically. Which I believe it can - see the RFS and XPS features in Linux. 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: IP_MINTTL and RFC5082 (TTL security, GTSM) support
On Aug 18, 2011, at 03:32 , Alexander V. Chernikov wrote:
> Hello list!
>
> FreeBSD supports IP_MINTTL since long ago (5.x ?). This is RFC3682-compatible
> implementation.
>
> It is very simple: if we can associate incoming packet with any socket,
> socket is checked for minimum TTL value existence. If such value exists and
> received packet TTL is lower, packet is dropped.
>
> However, it is not enough for real security. ICMP messages are not checked
> for minimum TTL (which is now required by RFC 5082 6.1.)
>
> Icmp messages are passed via .pr_ctlinput upper level protocol hook.
> Icmp code, originator address (sockaddr *) and part of problem datagramm
> (received in icmp packet) are passed as arguments.
>
> As a result, TTL of ICMP packet is not passed to upper layer proto and TTL
> security cannot be enforced.
>
> What can possibly be done:
>
> * New hook .pr_ctlinput2 with additional argument pointing to original ICMP
> header can be added. After that we convert all base code to use .pr_ctlinput2
> and appropriate icmp_input() parts can be changed like this:
>
>
> ctlfunc2 = inetsw[ip_protox[icp->icmp_ip.ip_p]].pr_ctlinput2;
> if (ctlfunc2)
> (*ctlfunc2)(code, (struct sockaddr *)&icmpsrc,
>(void *)&icp->icmp_ip, (void *)icp);
> else {
> ctlfunc = inetsw[ip_protox[icp->icmp_ip.ip_p]].pr_ctlinput;
>if (ctlfunc)
> (*ctlfunc)(code, (struct sockaddr *)&icmpsrc,
> (void *)&icp->icmp_ip);
>
> }
>
> * .pr_ctlinput() can be altered (if it's not too late for 9.x) and some trick
> like supplying TTL data directly after (struct sockaddr*) can be used as 8.x
> MFC
>
>
> P.S. We should implement IP_MINTTL variant for IPv6. I can submit patches but
> this seems to be reasonable only after we got some solution for ICMP security.
>
> Linux people added compatible opt for IPv4 in 2.6.34:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d218d11133d888f9745802146a50255a4781d37a
>
> .. and IPV6_MINHOPCOUNT for IPv6 in 2.6.35:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e802af9cabb011f09b9c19a82faef3dd315f27eb
>
> so we can consider using IPV6_MINHOPCOUNT as appropriate setsockopt name
Sounds good. Do you have a patch already? It seems like you might.
Best,
George
___
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: Adding Flow Director sysctls to ixgbe(4)
On Fri, Sep 09, 2011 at 01:44:34AM +0100, Ben Hutchings wrote: > On Thu, 2011-09-08 at 20:13 -0400, George Neville-Neil wrote: > > On Sep 8, 2011, at 14:49 , Navdeep Parhar wrote: > > > > > On Thu, Sep 08, 2011 at 08:34:11AM -0400, John Baldwin wrote: > > >> On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > > >>> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > > Hi, > > > > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a > > detail: > > > > - Adding removing signature filter > > On linux version of ixgbe driver, it has ability to set/remove perfect > > filter from userland using ethtool command. > > I implemented similar feature, but on sysctl, and not perfect filter > > but signature filter(which means hash collision may occurs). > > >>> [...] > > >>> > > >>> Linux also has a generic interface to RX filtering and hashing > > >>> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > > >>> to support something like that? > > >> > > >> Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) > > >> drivers > > >> both provide their own tools to manipulate filters, though they do not > > >> provide explicit steering IIRC. > > > > > > Both of them can filter as well as steer (and the tools let you do that). > > > cxgbe(4) can do a lot more (rewrite + switch, replicate, etc.) but those > > > features are perhaps too specialized to be configurable via a general > > > purpose tool. > > > > > >> > > >> We would need to come up with some sort of standard interface (ioctls?) > > >> for > > >> adding filters however. > > > > > > +1 for a standard interface. > > > > > > imho the kernel needs to be aware of the rx and tx queues of a NIC, and > > > not just for steering. But that's a separate discussion. > > > > > > > Well I do think this is actually all of a part. Most of us realize by now > > that > > high speed (e.g. 10G and higher) NICs only make sense if you can steer > > traffic and > > pin queues to cores etc. > > Well, you can get way better than 1G performance without that. And for > routers, flow hashing may be fine. But for a host, of course, steering > packets properly can provide a major performance win. > > [...] > > What this means is that we have > > a failure of abstraction. Abstraction has a cost, and some of the people > > who want > > access to low level queues are not interested in paying an extra > > abstraction cost. > > Abstraction has a cost, but it's not necessarily that high compared to > rewriting a whole chunk of sockets code (especially if you don't > actually have the source code). > > > I think that some of the abstractions we need are tied up in the work that > > Takuya did > > for SoC and some of it is in the work done by Luigi on netmap. I'd go so > > far as to say > > that what we should do is try to combine those two pieces of code into a > > set of > > low level APIs for programs to interact with high speed NICs. The one > > thing most > > people do not talk about is extending our socket API to do two things that > > I think would > > be a win for 80% of our users. If a socket, and also a kqueue, could be > > pinned > > to a CPU as well as a NIC queue that should improve overall bandwidth for a > > large > > number of our users. The API there is definitely an ioctl() and the hard > > part is > > doing the tying together. To do this we need to also work out our low > > level story. > > But it would be a lot nicer if this could be done automatically. Which > I believe it can - see the RFS and XPS features in Linux. rwatson@ has been working on "connection groups" (not sure what he calls his project) with a goal to improve the placement of work in the FreeBSD network stack. Some of the code is in the kernel but the parts that require closer cooperation with a NIC are not. Regards, Navdeep ___ 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: Adding Flow Director sysctls to ixgbe(4)
On Sep 9, 2011, at 9:44 AM, Ben Hutchings wrote: > But it would be a lot nicer if this could be done automatically. Which > I believe it can - see the RFS and XPS features in Linux. Does it cooperate with hw queues and hw hashing now? When I saw RFS code, it was just worked with RPS. ___ 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"
