Hi fortville Experts,
Was trying to use VLAN Table (for filtering) in conjunction with MACVLAN table
mentioned in "7.4.8.3 L2 Filtering Algorithm" (also cut n' pasted below)
My test scenario:
1. In SRIOV mode, gave one VF to VM. For that, I added the corresponding MAC
into MACVLAN table with vlan=25
2. Added VLAN table with vlan=25. (For p.VPE=0 I used
'i40e_aqc_opc_set_vsi_promiscuous_modes' opcode with vlan promiscuous.)
Now the packets are coming into this VM.
1. Now, I delete the vlan=25 entry in the VLAN table (expecting that packets
stop coming in)
2. Packets are still coming in.
But I am confused with this behavior. According the algorithm below, Namely:
" EFilter = MFilter and (VFilter or p.VPE} and AddressType == Unicast;"
The packets should have stopped coming in. What am I missing?
Is there any global setting /register that I need to toggle for the VLAN table
to be effective?
Is VSI setup needs additional flags? Not sure
thanks,
Shankar.
I40e Driver Version: 1.2.37
7.4.8.3 L2 Filtering Algorithm
The following pseudo code describes the algorithm used to determine if a packet
passes the L2 filtering
element.
// Global parameters
// Define Lookup tables
MacVlan Table: Array of {MAC (MAC Address), VLAN (VLAN tag)}
Ethernet Controller XL710 - Internal Switch
728
Mac Table: Array of {MAC (MAC Address)}
VLAN table: Array of {VLAN (VLAN tag)}
HashMacVlan Table: Array of {HashMAC (Hash Values), VLAN (VLAN tag),
AddressType}
HashMac Table: Array of {HashMAC (Hash Values) , AddressType}
EtherType Table : Array of {Etype (Ethertypes Values)}
MacEtherType Table: Array of {MAC (MAC Address), Etype (Ethertype value)}
// Define Virtual ports modes
Port.PUE // Promiscuous Unicast Enable
Port.PME // Promiscuous Multicast Enable
Port.BAM // Broadcast Enable
Port.VPE // Promiscuous VLAN enable
Port.MaxSize: Max Packet size
L2_function(Packet)
// Variables
MFilter: = False // MAC Filtering
VFilter: = False // VLAN Filtering
EFilter: = False // Exclusive Filtering
NEPMFilter = False // Non Exclusive Perfect MAC Filtering
NEPFilter = False // Non Exclusive Perfect Filtering
NEIPMFilter = False // Non Exclusive Imperfect MAC Filtering
NEIPFilter = False // Non Exclusive Imperfect Filtering
Pass = False // Final decision.
//Define packet parameters
DA = Packet.DA //Destination Address of the packet
VID = Packet.VLAN ID // Vlan tag of the packet
Etype = Packet.Ethertype // Ethertype of the packet
AddressType //Type of address of the DA. Can be Unicast, Multicast or Broadcast.
HDA = HashFunction(DA).
PSize: Packet size. This do not include any tag or other header removed by
previous stages or to be added by following stages.
// Exclusive Filters
For Each entry e in MacVlan Table
If (DA == e.MAC and (VID == e.VLAN or (VID == NULL and e.VLAN == 0)) MFilter =
True;
For Each entry e in Mac Table
If (DA == e.MAC) MFilter = True;
For Each entry e in Ethertype Table
If (Etype == e.Etype) MFilter = True;
For Each entry e in MacEthertype Table
If (DA == e.MAC and Etype == e.Etype) MFilter = True;
For Each entry e in Vlan Table
If (VID == e.VLAN or (VID == NULL and e.VLAN == 0)) VFilter = True;
// VLAN filters are ANDed with the previous filters unless promiscuous VLAN is
enabled
EFilter = MFilter and (VFilter or p.VPE} and AddressType == Unicast;
// Non Exclusive Perfect Filters
If (AddressType == Unicast and p.PUE == 1) NEPMFilter = True;
If (AddressType == Multicast and (p.PME == 1 or MFilter)) NEPMFilter = True;
If (AddressType == Broadcast and (p.BAM == 1 or MFilter)) NEPMFilter = True;
// VLAN filters are ANDed with the previous filters unless promiscuous VLAN is
enabled
NEPFilter = NEPMFilter and (VFilter or p.VPE};
// Non Exclusive Imperfect Filters
For Each entry e in HashMACVlan Table
If (HDA == e.HashMAC and (VID == e.VLAN or (VID == NULL and e.VLAN == 0)) and
AddressType == e.AddressType) NEIPMFilter = True;
For Each entry e in HashMAC Table
If (HDA == e.HashMAC and AddressType == e.AddressType) NEIPMFilter = True;
// VLAN filters are ANDed with the previous filters unless promiscuous VLAN is
enabled
NIEPFilter = NIEPMFilter and (VFilter or p.VPE};
// Packet size filtering is done at the queue level, so it is not part of the
switch algorithm
Pass = (EFilter or NEPFilter or NEIPFilter)
Return Pass;
}
-----Original Message-----
From: Ronciak, John [mailto:john.ronc...@intel.com]
Sent: Tuesday, September 15, 2015 10:40 AM
To: Fujinaka, Todd <todd.fujin...@intel.com>; zheloba...@prosoftsystems.ru;
e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Intel 82551IL chips
As long as there is no copy and pasting from the Linux driver to the QNX driver
it should not be a problem. I'm not a lawyer but that's generally the case.
That said, since the driver works after another a second reboot it's probably
not related to the driver. This is probably something that is related to the
system during the PCI enumeration of devices. Are all the other devices seen
on a cold boot? Is there an equivalent to 'lspci' in QNX? If so what's it
show on the first boot from power-off? Are all the devices seen at that point
or are some missing?
Cheers,
John
> -----Original Message-----
> From: Fujinaka, Todd [mailto:todd.fujin...@intel.com]
> Sent: Tuesday, September 15, 2015 9:43 AM
> To: zheloba...@prosoftsystems.ru<mailto:zheloba...@prosoftsystems.ru>;
> e1000-devel@lists.sourceforge.net<mailto:e1000-devel@lists.sourceforge.net>
> Subject: Re: [E1000-devel] Intel 82551IL chips
>
> The 82551L has been EOLed for about nine years by my estimation. We
> don't have any further support for it.
>
> Also, it is probably a violation of the GPL to start with the Linux
> driver to work on the QNX driver. I would suggest trying the FreeBSD driver.
>
> Todd Fujinaka
> Software Application Engineer
> Networking Division (ND)
> Intel Corporation
> todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>
> (503) 712-4565
>
> -----Original Message-----
> From: Желобанов Дмитрий Владимирович
> [mailto:zheloba...@prosoftsystems.ru]
> Sent: Tuesday, September 15, 2015 5:15 AM
> To:
> e1000-devel@lists.sourceforge.net<mailto:e1000-devel@lists.sourceforge.net>
> Subject: [E1000-devel] Intel 82551IL chips
>
> Hello,
>
> We use chips 82551IL (did 0x1209 rev 0x10) in our embedded platforms.
> Our devices run QNX operation system. We faced with an issue:
> sometimes our devices don't receive Ethernet packets right after boot
> at all, only reboot helps to revive the devices. We think the root
> problem is in hardware- software communication with the Ethernet
> controller, or rather in QNX Ethernet driver.
> I looked in Linux driver (e100.c) and found, the driver uploads
> special firmware in chips like ours.
>
> So, could you give us a document which clarifies changes in
> d102e_ucode.bin firmware from the original on chip microcode?
>
> Желобанов Д.В.
> ООО <Прософт-Системы>, г. Екатеринбург.
>
>
> ----------------------------------------------------------------------
> -------- _______________________________________________
> E1000-devel mailing list
> E1000-devel@lists.sourceforge.net<mailto:E1000-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/e1000-devel
> To learn more about Intel® Ethernet, visit
> http://communities.intel.com/community/wired
------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net<mailto:E1000-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
