Thread (57 messages) 57 messages, 12 authors, 2009-11-30

Re: ixgbe question

From: John Fastabend <hidden>
Date: 2009-11-24 20:46:10

Peter P Waskiewicz Jr wrote:
On Tue, 2009-11-24 at 02:55 -0700, Eric Dumazet wrote:
  
quoted
Peter P Waskiewicz Jr a écrit :

    
quoted
You might have this elsewhere, but it sounds like you're connecting back
to back with another 82599 NIC.  Our optics in that NIC are dual-rate,
and the software mechanism that tries to "autoneg" link speed gets out
of sync easily in back-to-back setups.

If it's really annoying, and you're willing to run with a local patch to
disable the autotry mechanism, try this:
diff --git a/drivers/net/ixgbe/ixgbe_main.c
b/drivers/net/ixgbe/ixgbe_main.c
index a5036f7..62c0915 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -4670,6 +4670,10 @@ static void ixgbe_multispeed_fiber_task(struct
work_struct *work)
        autoneg = hw->phy.autoneg_advertised;
        if ((!autoneg) && (hw->mac.ops.get_link_capabilities))
                hw->mac.ops.get_link_capabilities(hw, &autoneg,
&negotiation);
+
+       /* force 10G only */
+       autoneg = IXGBE_LINK_SPEED_10GB_FULL;
+
        if (hw->mac.ops.setup_link)
                hw->mac.ops.setup_link(hw, autoneg, negotiation, true);
        adapter->flags |= IXGBE_FLAG_NEED_LINK_UPDATE;
      
Thanks ! This did the trick :)

If I am not mistaken, number of TX queues should be capped by number of possible cpus ?

Its currently a fixed 128 value, allocating 128*128 = 16384 bytes,
and polluting "tc -s -d class show dev fiber0" output.

    
Yes, this is a stupid issue we haven't gotten around to fixing yet.
This looks fine to me.  Thanks for putting it together.

  
Believe the below patch will break DCB and FCoE though, both features 
have the potential to set real_num_tx_queues to greater then the number 
of CPUs.  This could result in real_num_tx_queues > num_tx_queues. 

The current solution isn't that great though, maybe we should set to the 
minimum of MAX_TX_QUEUES and num_possible_cpus() * 2 + 8.

That should cover the maximum possible queues for DCB, FCoE and their 
combinations. 

general multiq = num_possible_cpus()
DCB = 8 tx queue's
FCoE = 2*num_possible_cpus()
FCoE + DCB = 8 tx queues + num_possible_cpus

thanks,
john.


quoted
[PATCH net-next-2.6] ixgbe: Do not allocate too many netdev txqueues

Instead of allocating 128 struct netdev_queue per device, use the minimum
value between 128 and number of possible cpus, to reduce ram usage and
"tc -s -d class show dev ..." output
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index ebcec30..ec2508d 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -5582,7 +5583,10 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
 	pci_set_master(pdev);
 	pci_save_state(pdev);
 
-	netdev = alloc_etherdev_mq(sizeof(struct ixgbe_adapter), MAX_TX_QUEUES);
+	netdev = alloc_etherdev_mq(sizeof(struct ixgbe_adapter),
+				   min_t(unsigned int,
+					 MAX_TX_QUEUES,
+					 num_possible_cpus()));
 	if (!netdev) {
 		err = -ENOMEM;
 		goto err_alloc_etherdev;
    
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help