I was asked about the maximum number of flow rules an OpenFlow switch can have, so I read the OpenFlow 1.5.1 specification but still couldn't find the answer.
Thank you.
As said by #SotirisTsartsaris, the number, size and characteristics of the flow tables are only dependent on the switch, not defined by the specification.
Related
I am working with OVS switchs and I want to know how many rules or flows they can support.
Thanks
You can find its limitations in OVS doc limit section:
Kernel flows limit:
Kernel flows are limited only by memory available to the kernel.
Performance will degrade beyond 1,048,576 kernel flows per
bridge with a 32-bit kernel, beyond 262,144 with a 64-bit kernel
OpenFlow flows limit:
OpenFlow flows are limited only by available memory. Performance
is linear in the number of unique wildcard patterns.
If I get in correctly:
queueFamily is a set of queues
queue could have more than one queue flag
there are 4 types of queue flags(graphics, compute, transfer and sparse binding)
I'm trying to enumerate all informations about a single queue family. First I chceck how many queue families are available, next how many queues every of queue family has, and how many queue flags family supports.
It's enough to know that I have queue family that supports e.g queue graphics flag, or in future I will have to go deeper and check for particular queue from specific queue family?
All queues from a single family have the same properties (the same set of flags). So You don't have to go deeper and check each queue.
But there 3 things You need to remember. Spec guarantees that there must be at least one universal queue which supports graphics and compute operations. Second thing is that different queue families may have the same properties (the same set of flags). And last thing - swapchain presentation (ability to present swapchain image to a given surface) is also a queue family property, but it must be checked through a separate set of queries (functions).
or in future
That is basically Q about versioning and extensions.
Major versions are allowed to make any changes (i.e being "uncomapatible"). So you will potentially have to do things differently in the app. But it is conceivable old major versions will still be available alogside new versions.
Minor versions, and extensions are supposed to be backwards-compatible (with notable exceptions). But only on ABI level, so there is no absolute guarantee your program will compile with new header.
That means driver update should not break your already compiled app.
(The notable exceptions are):
*Flags returned from Vulkan may have unspecified bits (i.e. bits that are not specified within spec of version you are using with the extensions you have enabled)
enums returned from Vulkan may have unspecified values
if you actively try to crash your app, such as if( vulkanVersion != 1.0.0 ) crash();
the compatibility (obviously?) does not apply to things that are not purely functional (i.e. does not apply to performance, watts, noise, or whatever)
if you use any of the new stuff, Vulkan expects you to know all of it — e.g. if your app is mostly Vulkan 1.0, and Vulkan returns flag from Vulkan 1.42 alongside graphics you have not yet bothered to learn, then you later use another flag bit defined by 1.42 in another command, it may interact with the queue flag somehow.
any version is allowed to incompatibly fix Spec bug (or what authors decide to consider one)
?
I was trying to download VxWorks 5.x (specifically 5.11) manual, to understand the limitations with respect to the number of tasks, message queues, stack sizes , memory restrictions and semaphores.
Can any one of you please post any link to download or share the above-mentioned limitations?
There are not, as far as I am aware, any inherent limits in the number of tasks, message queues, stack sizes, sempahores etc.
While there clearly will be an upper bound, this is primarily dictated by the hardware platform, in particular the amount of memory.
This is especially true of message queues, and the stack size for various tasks.
If you are after particular documentation, you should contact your WindRiver support rep - documentation is freely available to all licensed users
I want to to execute the SPI protocol operation using GPIO Pins, want to configure to single slave operation, in which way I have to configure that, I am using STM32F100RB Microcontroller and Coocox IDE for this executing in windowsxp.
if any body have example source code regarding the configuration of SPI Protocol operation using GPIO pins, then please send me that.
it very helpful for my project, Thanks in advance.
Regards,
Pavan Neo.
You're asking about Bit banging. This is the process of using an IO (or several) to encode or decode a serial signal. Wikipedia has a good description of this process.
For SPI specifically, you will need two or three outputs (depending on whether or not chip select is needed) and one input. You'll have to ensure that your bits are set or read in the correct order to not violate any setup/hold requirements of your peripheral, and you'll need to pay attention to the polarity needed on the clock signal (to make sure you're reading/writing data on the correct edge).
The Wikipedia link has some example code for bit banging that you may find useful as a starting point.
Iam doing a project to recognize gestures by reading adc values in pic 16f73 using embedded c. Everything works fine while using single adc channel. When i use multiple channels, values are affected each other. is this a hardware error or software problem?
Probably. It's very likely to be one, or the other, or both. Split problem in half.
Eliminate one at a time. Scope/meter on both analog inputs. Change one input - does the other change too? If it does, there is a hardware issue at least. If not, it's software.
This is debugging 101.
It's a hardware effect, but not an error.
From the datasheet:
11.1 A/D Acquisition Requirements
For the A/D converter to meet its specified accuracy,
the charge holding capacitor (CHOLD) must be allowed
to fully charge to the input channel voltage level. The
analog input model is shown in Figure 11-2. The source
impedance (RS) and the internal sampling switch (RSS)
impedance directly affect the time required to charge
the capacitor CHOLD. The sampling switch (RSS)
impedance varies over the device voltage (VDD), see
Figure 11-2. The source impedance affects the offset
voltage at the analog input (due to pin leakage current).
The maximum recommended impedance for analog sources is 10 kΩ. After the analog input channel is
selected (changed), the acquisition period must pass
before the conversion can be started.
To calculate the minimum acquisition time, TACQ, see
the PICmicro™ Mid-Range MCU Family Reference
Manual (DS33023). In general, however, given a maximum source impedance of 10 kΩ and at a temperature
of 100°C, TACQ will be no more than 16 µsec.
It will likely be because you have high impedance sources driving all the ADC pins. When the multiplexer switches from one input to the next, any charge that is stored on the sampling capacitor of the ADC from the previous input will still be there.
If you drive each input with the output of a suitable op amp, when the ADC's multiplexer switches, the op amp is able to drive charge in or suck charge out of the sampling capacitor and the time needed for the new input you are reading can be significantly reduced. Plus, with this method you are not loading the voltage you are wanting to read.
If you cannot drive with a low impedance source, then ensure you have plenty of time for the new input's value to settle.