n Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com
-Original Message-
From: Chris Friesen
Sent: Friday, January 15, 2021 12:20 PM
To: Fujinaka, Todd ; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] IRQ affinity not working for iavf devices?
The irqbalan
aka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com
-Original Message-
From: Chris Friesen
Sent: Tuesday, January 12, 2021 3:53 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] IRQ affinity not working for iavf devices?
Hi,
I have
Hi,
I have a CentOS 7 linux system with 48 logical CPUs and a number of
Intel NICs running the i40e driver. It was booted with
irqaffinity=0-1,24-25 in the kernel boot args, resulting in
/proc/irq/default_smp_affinity showing ",0303". CPUs 2-11 are
set as "isolated" in the kernel b
On 12/01/2016 01:51 PM, Fujinaka, Todd wrote:
> i40evf will be updated by early Q1 2017. Otherwise, the latest drivers
> compile on RHEL 7.3.
For what it's worth, I was not able to compile the latest ixgbe/ixgbevf on 7.3.
I took the 7.3-related src/kcompat.h changes from i40e driver and applie
On 11/29/2016 11:09 AM, Fujinaka, Todd wrote:
> In general we don't mention version numbers of OSes and I don't expect we'll
> start.
>
> I can also tell you that we also posted newer versions of the other three
> drivers.
Could you point me towards these newer versions? The latest "i40evf stab
On 11/29/2016 09:33 AM, Fujinaka, Todd wrote:
> I would suggest you check e1000.sourceforge.net and see that there's three
> newer drivers than the one you're using. The latest should compile on
> RHEL7.3.
I did check there. The changelogs don't say anything about support for 7.3,
and
I assumed
I recently tried compiling i40e version 1.5.19 on CentOS 7.3 and it crapped all
over. I've attached the logs to preserve line length.
It looks like they've backported some stuff in a way that breaks assumptions in
a bunch of the Intel out-of-tree drivers.
Are there plans to add support for 7
Hi all,
I'm running a 3.10 kernel with the builtin ixgbe driver.
I have an 82599 device (eth5) that is being added to a bond (bond0), and there
is an application which is trying to listen for multicast packets on 224.0.0.1
port 2106.
Somehow (and I'm not sure how yet) we get into a state where
On 11/16/2012 08:45 AM, Chris Friesen wrote:
> Are you eventually going to be adding the IGBVF_FLAG_RX_LB_VLAN_BSWAP
> flag to the mainline igbvf driver or should I also send in a patch for
> that?
>
> I am a bit curious about the endianness thing. The datasheets for both
>
From: Chris Friesen
In igbvf_receive_skb() the VLAN tag is big-endian while the mask is
cpu-endian. We need to convert both to common endianness before
applying the mask.
Signed-off-by: Chris Friesen
Reported-by: Mark Huang
---
diff --git a/src/netdev.c b/src/netdev.c
index a18f000..260a598
On 11/15/2012 06:40 PM, Williams, Mitch A wrote:
> OK, got it reproduced and fixed. Turns out that your fix with the
> masking and byte swapping was spot on.
>
> If you want to respin your patch to remove the unconditional setting
> of the IGBVF_FLAG_RX_LB_VLAN_BSWAP flag, you should be good to go.
On 11/14/2012 02:23 PM, Williams, Mitch A wrote:
> NAK, at least the second half. The IGBVF_FLAG_RX_LB_VLAN_BSWAP tag is
> specifically to work around an errata on the i350. This change would
> break the 82576.
I see that you're explicitly checking for loopback packets and only
converting from bi
There seems to be a bug in the igbvf sourceforge driver. In igbvf_receive_skb()
we're ANDing the big-endian vlan ID with the little-endian mask.
Also, I think the criteria for setting IGBVF_FLAG_RX_LB_VLAN_BSWAP is incorrect.
The 82576 datasheet also indicates that the VLAN tag is big endian. Sin
On 11/13/2012 05:53 PM, Wyborny, Carolyn wrote:
>> From: Chris Friesen [mailto:chris.frie...@genband.com]
>> With the older kernel but the latest igb/igbvf drivers we're having
>> issues as follows:
>>
>> We can send vlan-tagged packets from a different system
On 11/13/2012 04:48 PM, Vick, Matthew wrote:
> I took a look at this with Carolyn and I believe what you're seeing
> is the expected behavior. In these older kernels, there was no
> ethtool option to turn on and off VLAN stripping on the fly. If you
> look, the get_flags operation just calls ethto
On 11/08/2012 02:58 PM, Chris Friesen wrote:
> I tried
> using "ethtool -K ethX rxvlan off" but for some reason that option
> always showed as off even when CTRL.VME was actually set.
This is not my main problem, but somewhat related. I think I found a
flaw in the driver.
I
On 11/06/2012 02:27 PM, Chris Friesen wrote:
> On 11/06/2012 02:10 PM, Chris Friesen wrote:
>
>> I'm doing a test to see if not stripping the vlan tag will make any
>> difference.
>
> So I applied this patch (basically just disabling vlan stripping for VFs)
&
On 11/06/2012 02:10 PM, Chris Friesen wrote:
> I'm doing a test to see if not stripping the vlan tag will make any
> difference.
So I applied this patch (basically just disabling vlan stripping for VFs)
and vlan-on-vf to vlan-on-vf communication now seems to be working.
diff --gi
On 11/06/2012 01:52 PM, Chris Friesen wrote:
> On 11/06/2012 01:34 PM, Chris Friesen wrote:
>
>> Is there something that can cause the internal switch to strip the vlan
>> header?
>
> I'm looking at the drivers, and it seems like if the VF sends a
> E1000_
On 11/06/2012 01:34 PM, Chris Friesen wrote:
> Is there something that can cause the internal switch to strip the vlan
> header?
I'm looking at the drivers, and it seems like if the VF sends a
E1000_VF_SET_VLAN message specifying a particular VLAN ID then the PF
On 11/06/2012 01:15 AM, Levy, Lior wrote:
> This behavior/message occurs due to setting a "port" VLAN from the PF
> side. Administratively VLAN can be set by the PF using the ip command
> 'ip link set vf vlan'. When setting VLAN ID from
> the VF/VM side port VLAN cannot be used.
Yeah, we figure
On 11/05/2012 01:59 PM, Chris Friesen wrote:
> On 11/05/2012 10:26 AM, Levy, Lior wrote:
>> Hi Chris,
>>
>> I just remembered that we had a problem with I350 regarding VLAN
>> connectivity between VFs.
>> We resolved the issue lately. Did you use the latest ig
On 11/05/2012 10:26 AM, Levy, Lior wrote:
> Hi Chris,
>
> I just remembered that we had a problem with I350 regarding VLAN connectivity
> between VFs.
> We resolved the issue lately. Did you use the latest igbvf driver on
> sourceforge? ver 2.0.4 is available.
Moving to igbvf-2.0.4 doesn't seem
993 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:85606 (83.5 KiB) TX bytes:124878 (121.9 KiB)
Any help you can provide would be appreciated.
Thanks,
Chris
--
Chris Friesen
Software Designer
3500 Carling Avenue
Ottawa, Ontario K2H 8E9
www.g
ges
are mostly vlan-related. If we're not using vlans do we need to worry
about this?
Thanks,
Chris
--
Chris Friesen
Software Designer
3500 Carling Avenue
Ottawa, Ontario K2H 8E9
www.genband.com
--
Live Se
On 08/17/2012 08:45 AM, Alexander Duyck wrote:
>
> The RSS option was updated a while back to control the number of queues
> that a workload can be distributed over in a non-DCB mode. Setting it
> to 0 is only going to give you one queue per port.
>
> If you are wanting the behaviour to be that al
On 08/16/2012 05:07 PM, Chris Friesen wrote:
> On 08/16/2012 04:00 PM, Waskiewicz Jr, Peter P wrote:
>> If you disable RSS, then all non-matched FDIR flows will go to queue 0
>> by default. If you're using the upstream driver, you'll need to comment
>> out the R
On 08/16/2012 04:00 PM, Waskiewicz Jr, Peter P wrote:
> If you disable RSS, then all non-matched FDIR flows will go to queue 0
> by default. If you're using the upstream driver, you'll need to comment
> out the RSS_ENABLED flag in the code and recompile. If you're using the
> SourceForge driver,
Okay, I've been playing around with flow director and perfect filters.
I used the default module parameters to get 32 queues, then did "ethtool
-K ethX ntuple on" to allow the use of flow director perfect filters.
I've set up 31 filter rules to route IP traffic destined for a specific
IP addr
On 08/15/2012 05:21 PM, Chris Friesen wrote:
> On 08/15/2012 04:08 PM, Chris Friesen wrote:
>> On 08/13/2012 12:35 PM, Alexander Duyck wrote:
>>
>>> Instead of using the FdirMode parameter one thing you could try
>>> doing is
>>> just using the "et
On 08/15/2012 04:08 PM, Chris Friesen wrote:
> On 08/13/2012 12:35 PM, Alexander Duyck wrote:
>
>> Instead of using the FdirMode parameter one thing you could try doing is
>> just using the "ethtool -K" option to turn on ntuple filtering in order
>> to enable pe
On 08/13/2012 12:35 PM, Alexander Duyck wrote:
> Instead of using the FdirMode parameter one thing you could try doing is
> just using the "ethtool -K" option to turn on ntuple filtering in order
> to enable perfect filters.
Ah, there we go. I'm seeing some odd behaviour though, if I specify an
On 08/08/2012 05:20 PM, Brandeburg, Jesse wrote:
> You can enable flow-director on UDP packets with ethtool.
What's the command for that? I'm using ixgbe 3.6.7, does it support
that or do I need to upgrade?
Also, I tried enabling perfect filters (xgbe.FdirMode=2,2,2,2,
everything else set to
On 08/03/2012 11:49 AM, Ben Hutchings wrote:
> On Thu, 2012-08-02 at 21:50 -0700, John Fastabend wrote:
>> Perhaps one argument against this is if the hardware supports loopback
>> modes or the edge relay in the hardware is acting like a VEB it may
>> still be possible to support VF to VF traffic
On 08/08/2012 03:48 PM, Skidmore, Donald C wrote:
> Of course if your app isn't producing TCP flows this won't help at all. ATR
> only works with TCP.
Hmm...that's not ideal.
If I understand correctly though if FDIR fails it falls back to a
RSS-style hash to try and spread the load across mult
> Hey Chris,
>
> With the default ixgbe configuration you should have ATR enabled, which will
> mean that you should end up with 32 queue one for each CPU. If you run the
> set_irq_affinity.sh script each queue will be affinitized to a CPU. Now any
> flows initiated from that CPU will be assoc
S mode only gives 16 queues, but when
using virtualization I can get up to 64 pools. Can I use VMDq to get
the extra pools/queues without actually starting up VMs? Can I assign
multiple MAC addresses to the various pools/queues? How would I do this
given the current driver?
Thanks,
Chris
On 08/02/2012 05:01 PM, Jay Vosburgh wrote:
> Chris Friesen wrote:
> Still, though, isn't "influence the guest's choice" pretty much
> satisified by having the VF interface go carrier down in the guest when
> the host wants it to? Or are you thinking abo
On 08/02/2012 04:26 PM, Chris Friesen wrote:
> On 08/02/2012 02:30 PM, Jay Vosburgh wrote:
>> The best long term solution is to have a user space API that
>> provides link state input to bonding on a per-slave basis, and then some
>> user space entity can perform whatever l
On 08/02/2012 02:30 PM, Jay Vosburgh wrote:
>
> Chris Friesen wrote:
>> 2) If both the host and guest use active/backup but pick different
>> devices as the active, there is no traffic between host/guest over the
>> bond link. Packets are sent out the active and loop
VM or something. Anyone have any bright ideas?
I'm sure we're not the only ones running into this, so what are others
doing? Is the only current option to use active/active with miimon?
Chris
--
Chris Friesen
Software Designer
3500 Carl
On 08/01/2012 12:12 PM, Alexander Duyck wrote:
> Do you have any specific reason
> for wanting to change this code? If not I would rather not change it
> since as is it is probably more appropriate then splitting up the RSTI
> and RSTD bit reads.
Thanks for the full explanation. I don't have any
On 08/01/2012 10:06 AM, Alexander Duyck wrote:
> On 07/31/2012 03:07 PM, Chris Friesen wrote:
>
>> 2) When the PF detects a link status change (presumably via interrupt)
>> it sends a notification of this via mailbox messages to the VFs. This
>> would then result in
On 08/01/2012 09:38 AM, Alexander Duyck wrote:
> On 07/31/2012 02:40 PM, Chris Friesen wrote:
>> There is a comment in ixgbe_reset_hw_vf() in the ixgbevf driver that
>> says, "we cannot reset while the RSTI / RSTD bits are asserted".
>>
>> According to the
On 07/31/2012 02:37 PM, Chris Friesen wrote:
> So is it really the case that it can take up to two seconds for the
> ixgbevf driver to notice loss of carrier?
>
> If so, I'm quite surprised. I would have expected this to be instant.
If this is in fact the case, I would
STI is set.
Whether or not this is worth another function pointer I'm not sure, but
maybe the comment could be fixed up. :)
Chris
--
Chris Friesen
Software Designer
3500 Carling Avenue
Ottawa, Ontario K2H 8E9
www.genband.com
---
seconds.
So is it really the case that it can take up to two seconds for the
ixgbevf driver to notice loss of carrier?
If so, I'm quite surprised. I would have expected this to be instant.
Chris
--
Chris Friesen
Software Designer
3500 Carling Avenue
Ottawa, Ontario
On 07/25/2012 02:44 PM, Greg Rose wrote:
> Chris Friesen wrote:
>
>> Just noticed something suspicious in ixgbe_ndo_set_vf_mac().
>>
>> We set adapter->vfinfo[vf].pf_set_mac twice, once unconditionally and
>> then once conditionally. Should that first one be del
o use the VF device.\n");
}
} else {
dev_warn(&adapter->pdev->dev, "The VF MAC address was NOT set
due to invalid or duplicate MAC address.\n");
}
ret
this with sysfs or something?
Thanks,
Chris
--
Chris Friesen
Software Designer
3500 Carling Avenue
Ottawa, Ontario K2H 8E9
www.genband.com
--
Live Security Virtual Conference
Exclusive live event will cover al
On 06/08/2012 02:14 PM, Chris Friesen wrote:
>
> Hi,
>
> I'm using the igb/igbvf drivers. If I set igb.max_vfs=7,7,7,7 it
> creates 7 vfs for each of my pfs. So far so good.
>
> Now, how do I map from a given pf to the PCI addresses for the set of
> vfs that are
nd rewritten
> parts of the PHY code to support the Broadcom PHY. As such if you are
> looking for updates to that driver I would recommend going back to the
> vendor who supplied you with that ATCA board for support.
That's basically what I figured. Will do, thanks for your help.
On 11/07/2011 06:41 PM, Wyborny, Carolyn wrote:
-Original Message- From: Chris Friesen
I've got a board for which the vendor has supplied an igb driver
claiming to be version 3.0.3. I assume it's got some
vendor-specific modifications but I don't know what they are.
On 11/07/2011 06:41 PM, Wyborny, Carolyn wrote:
>> -Original Message-
>> From: Chris Friesen [mailto:chris.frie...@genband.com]
>> I've got a board for which the vendor has supplied an igb driver
>> claiming to be version 3.0.3. I assume it's got some ve
n of 3.0.3?
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.frie...@genband.com
www.genband.com
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p
On 09/26/2011 11:24 AM, Ben Greear wrote:
> On 09/26/2011 09:40 AM, Chris Friesen wrote:
>> To any of the Intel guys out there...any ideas? Can an 82599 on an 8x
>> bus handle max line rate with minimum size packets?
>
> Rick Jones sent me an interesting link related to thi
n an 82599 on an 8x
bus handle max line rate with minimum size packets?
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.frie...@genband.com
www.genband.com
--
All the data continuously generated in your IT i
On 10/22/2010 04:41 PM, Brandeburg, Jesse wrote:
> On Fri, 22 Oct 2010, Chris Friesen wrote:
>>> Where do we go from here? If this is something that occurs on other
>>> boards would it make sense for the driver to provide a way to turn off
>>> the automaski
On 10/22/2010 11:06 AM, Chris Friesen wrote:
> On 10/12/2010 11:08 AM, Chris Friesen wrote:
>
>> On 10/08/2010 04:36 PM, Brandeburg, Jesse wrote:
>>
>>> seems reasonable, it should work okay. Does it fix the problem? It seems
>>> there must be a rac
On 10/12/2010 11:08 AM, Chris Friesen wrote:
> On 10/08/2010 04:36 PM, Brandeburg, Jesse wrote:
>> seems reasonable, it should work okay. Does it fix the problem? It seems
>> there must be a race between when the interrupt gets re-enabled and when
>> the hardware clears
On 10/08/2010 04:36 PM, Brandeburg, Jesse wrote:
> On Fri, 8 Oct 2010, Chris Friesen wrote:
>> I've attached a possible patch based on this premise, and I also moved
>> the interrupt disable code to
>> ixgbe_msix_clean_tx/ixgbe_msix_clean_rx/ixgbe_msix_clean_many where
&
.
>
> do you happen to be running with rx-usecs = 0/InterruptThrottleRate
> set?
rx-usecs shows as 125 (I don't think we set it), and
InterruptThrottleRate is the default value.
Chris
--
Chris Friesen
Software Developer
G
On 10/08/2010 12:34 PM, Chris Friesen wrote:
> On 10/08/2010 12:03 PM, Brandeburg, Jesse wrote:
>> To me this sounds extremely like an interrupt enable race, possibly at the
>> hardware level with your chipset that is implementing MSI-X
>>
>> One thing we can do is
ed to the MSI-X routines, to make sure the
> driver writes EICR to clear the bit that was asserted.
So basically we'd set the tx/rx queue bits in EIAC to zero at init time
and then in ixgbe_clean_rxtx_many() (in my specific case) we'd call
ixgbe_irq_disable_queues()? Is anything else needed?
Chris
-
On 10/08/2010 11:14 AM, Chris Friesen wrote:
> Given the above, it appears that we're somehow getting into a state
> where the interrupts are automatically disabled but then the driver
> doesn't re-enable them right away. Eventually it does re-enable them,
> but we'
blem go away.
Anyone got any ideas what might be going on?
Chris
PS The manual says that EICS and EIMC are both write-only, yet the
driver reads both of them for the register dump and reads EICS for
actual operation. Is this using undocumented behaviour?
--
Chris Friese
saw the problems running at 10G over the XAUI link but I'm currently
testing it at 1G to see if that improves reliability.
> All of this might be better done through factory support, if you have
> it.
I think we probably have access to someone. I can pursue it through
those channels if th
On 09/07/2010 04:16 PM, Chris Friesen wrote:
> I'm investigating an issue where under load we eventually suddenly stop
> receiving packets. We're sending out packets, I can see the reply being
> sent with tcpdump on other hosts, but we never receive the reply. The
> d
eport 0x744bef80
which is what I expected.
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.frie...@genband.com
www.genband.com
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programm
nd were being overridden by
subsequent code. Once I put it in a suitable place, setting AUTOC.LMS
to IXGBE_AUTOC_LMS_10G_SERIAL was enough to "break" the link.
Thanks for the help,
Chris
--
Chris Friesen
Software Developer
GENBAND
chri
possibly detect a link
as present?
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.frie...@genband.com
www.genband.com
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to
On 05/18/2010 04:01 PM, Waskiewicz Jr, Peter P wrote:
> I agree with Jesse, we need an EEPROM dump. Also, which driver version
> are you using, and what is the device ID of the board you're using?
> There are a few designs in the field using XAUI, just want to see
> which one you're using.
On 05/18/2010 03:08 PM, Jesse Brandeburg wrote:
> On Tue, 2010-05-18 at 13:53 -0700, Chris Friesen wrote:
>> Any ideas what might be happening here?
>
> None that immediately come to mind, I forwarded this to our hardware
> engineering however to take a look.
Much appreciated
after 100ms we transition
to the proper register values for a normal "up" link, then 45ms later we
lose the alignment status (but still have good lane sync status), and
finally 100ms later we lose signal detect
Hi,
I've got a question about the driver initialization. I have a card
(device ID IXGBE_DEV_ID_82599_XAUI_LOM) that is set up to use the 10G
XAUI interface.
In this circumstance with the speed nailed to 10G and autonegotiation
off, does it really make sense to use smartspeed? It ends up taking
I raised an issue a while back about problems where RAL[0] or RAH[0]
(but never both) would get zeroed out.
I used the cpu debug registers to trap on any writes to RAL[0] or
RAH[0]. The instrumentation detected the initial MAC address setup and
the modification of the MAC when adding the link to
On 03/18/2010 05:46 PM, Waskiewicz Jr, Peter P wrote:
> Chris,
>
>
>
> We had some interesting MAC address issues with multiple addresses in
> earlier drivers. Please try the bonding test with 2.0.62.4 and let
> us know how it goes. While we haven't seen anything specific to your
> reported is
driver as well?
Thanks again,
Chris Friesen
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See
instead of eth4.
(Same device type.)
Are you aware of any glitches in this area? Any suggestions on how to
handle it? (Unfortunately upgrading to a newer kernel isn't an option,
though a new driver might be possible.)
Thanks,
Chris Friesen
On 10/09/2009 05:48 PM, Alexander Duyck wrote:
> The odds of any 2 flows overlapping when you are only using 4 flows is
> pretty high, especially if the addresses/ports are close in range. You
> typically need something on the order of about 16 flows over a wide
> range of port numbers in orde
On 10/09/2009 02:22 PM, Brandeburg, Jesse wrote:
> On Fri, 9 Oct 2009, Chris Friesen wrote:
>> I've got some general questions around the expected behaviour of the
>> 82576 igb net device. (On a dual quad-core Nehalem box, if it matters.)
> the hardware you have only suppo
Hi all,
I've got some general questions around the expected behaviour of the
82576 igb net device. (On a dual quad-core Nehalem box, if it matters.)
As a caveat, the box is running Centos 5.3 with their 2.6.18 kernel.
It's using the 1.3.16-k2 igb driver though, which looks to be the one
from ma
82 matches
Mail list logo
