Though the PCIe Error reporting, Interrupt Simulation ( INTA,INTB,Etc) happens through PCIe Message Transaction, why there is a need for separate Hardware to generate the PCIe Msg/VDM Transaction?
By doing any changes in the Root-Complex driver, is it possible to create custom API's for applications to generate PCIe MSG Transaction?
Thanks in Advance
The answer is: Yes.
I have based my answer on my understanding that if PCIe devices are moved to software and connected to a hardware root complex, there is a definite productive PCIe device prototyping in software and interactions with the real PCIe elements connected to the hardware root complex. Furthermore, we can examine the PCIe transactions at the software PCIe device without utilizing dedicated hardware system. For instance in the case of IP networks; IP network stacks at end hosts are software, however, the routers and switches are hardware.
Please check this reference NetTLP: A Development Platform for PCIe devices in Software Interacting with Hardware. It does mention a simple messaging API concept.
Related
I am testing a custom FPGA NIC and I need to send management information (such as header info for matching) and traffic data to it using a traffic generator from within the user space.
The driver built for the FPGA is a modified version of IXGBE with DMA support for management, and also supports DPDK for kernel bypass to achieve high throughput.
I am trying to understand how the various software (driver, userspace application, etc) should be stacked/connected to each-other so I can achieve the objective of reading and writing to PCIe on the NIC using set of scripts from user space?
I have also been looking at this project
https://github.com/CospanDesign/python-pci
which is useful however based on Xilinx XDMA.
Would appreciate any help, pointers on this.
Sorry, the question is too broad. For such a broad question there is a generic answer: have a look at Inter Process Communication:
https://en.wikipedia.org/wiki/Inter-process_communication
There are variety of methods, like Unix sockets, shared memory, netlink etc, to communicate between user space processes. As well as a variety of methods to communicate between user space and kernel space.
Just pick the best for you and try to do something. If it fails, come again on SO and ask ;)
guys
I am learning Linux Device Drivers.I have a question when reading below
"Since there is no equivalent of major and minor numbers for network interfaces, a network driver does not request such a number"
so could you please tell me why network interface has no major number or minor number by design?
Thanks
Major and minor numbers are used by character devices or block devices, and this implies that the user interacts with these devices by reading from and writing to special files (nodes), so a node may be created using the two numbers (major determines the device driver whilst minor is to specify a particular device managed by the driver).
Network drivers don't need the numbers since the approach (or design, as you say) of accessing network adapters doesn't assume their representation as files or nodes. Instead, the concept of network interfaces is used. And you typically make use of these network interfaces by means of socket API (say, Berkeley sockets), and such a kernel subsystem as network stack is involved here as an intermediate agent between your application and the network driver. There is no read/write access through files.
I was wondering that how can all different network devices have different MAC ID's.
is it hardcoded separately for each device ? (extremely unlikely..since in production nobody would like to change the code and recompile and load the program...)
or
a switch is used to set the address
or
is it loaded from the ROM ?
or something else ..
Many networking interfaces use EEPROMs that come pre-programmed with EUI-48 or EUI-64. They use EEPROMs to store configuration settings and other data anyway, so they don't have any additional cost using the pre-programmed EEPROMs other than the chips ending up slightly more expensive per 1k. Programming each device with a unique ID would however incur additional cost.
For instance, 24AA02xE is an I²C SEEPROM with pre-programmed EUI-48/EUI-64 at standard addresses. 93AA46AE48 is an SPI SEEPROM with pre-programmed EUI-48 that's directly compatible with LAN9xxx Ethernet Controllers.
I'm not affiliated with Microchip. I used their chips in a hobby project and noticed the datasheet mentioning the EUI-48 features.
I am trying to understand the working of wireless in linux. I started with wpa_supplicant, hostapd applications with the help of their documentation and source code.Understood the flow and basic functionalities of :
wpa_supplicant,nl80211(driver interface)
libnl library(socket communication between user space and kernel using netlink protocol)
cfg80211(kernel interface used for communicating with the driver from userspace with the help of nl80211 implementation in user space),mac80211(software media access control layer)
driver(loadable driver ex:ath6kl - atheros driver).
I understood the above software flow and in my exploration I came to know that for providing freedom for developers MAC layer is implemented in software(popular implementation mac80211).
Is this true in all the cases ? If so what are pros and cons of softMAC and hardMAC ? Do cfg80211 interface in kernel directly communicates with the driver ? who and how communication with mac80211 happens ?
Thanks in advance.
The term 'SoftMAC' refers to a wireless network interface device (WNIC) which does not implement the MAC layer in hardware, rather it expects the drivers to implement the MAC layer.
'HardMAC' (also called 'FullMAC') describes a WNIC which implements the MAC layer in hardware.
The advantages of SoftMAC are:
Potentially lower hardware costs
Possibility to upgrade to newer standards by updating the driver only
Possibility to correct faults in the MAC implementation by updating the driver only
An additional advantage (in the Linux kernel at least) is that many different drivers for different types of WNIC can all share the same MAC implementation, provided by the kernel itself.
Despite the advantages, not all WNICs use SoftMAC. The main advantages of HardMAC is that since the MAC functions are implemented in hardware, they contribute less CPU load.
mac80211 is the framework within the Linux kernel for implementing SoftMAC drivers. It implements the cfg80211 callbacks which would otherwise have to be implemented by the driver itself, and also implements the MAC layer functions. As such it goes between cfg80211 and the SoftMAC drivers.
HardMAC drivers have to implement the cfg80211 interfaces fully themselves.
Also to add :-
Hardmac drivers helps in better as compared to SoftMAC, power save and quick connection/disconnection recovery due to MLME implemented in HW. Better power save is because HW/FW need not to wake up host on disconnection and still can connect and recover .
few days ago I asked here about implementing USB. Now, If I may, would like to ask few more questions, about thing I dind´t quite understood.
So, first, If I am right, Windows has device driver for USB interface, for the physical device that sends and receives communication. But what this driver offers to system (user)? I mean, USB protocol is made so its devices are adressed. So you first adress device than send message to it.
But how sophisticted is the device controller (HW) and its driver? Is it so sophisticated that it is a chip you just send device adress and data, and it writes the outcomming data out and incomming data to some internal register to be read, or thru DMA directly to memory?
Or, how its drivers (SW) really work? Does its driver has some advanced functions like send _data to _device? Becouse I somewhat internally hope there is a way to directly send some data thru USB, maybe by calling USB drivers itself? Is there any good article, tutorial you know about to really explain how all this logic works? Thanks.
The USB protocol stack has several layers and is quite complex. You really need to read a good book on USB (e.g. USB Complete) to get an understanding of how it all fits together. The bottom line though is that you want to go as high up the protocol stack as you can, ideally using a system level API (e.g. if it's a USB HID device then just treat it like any other HID device, rather than thinking if it as a USB device - ditto for mass storage devices, etc).