Re: Adding Flow Director sysctls to ixgbe(4)
> What this means is that we have > a failure of abstraction. Abstraction has a cost, and some of the people who > want > access to low level queues are not interested in paying an extra abstraction > cost. I think a case can be made that that isn't necessarily the case depending on how well the abstraction is defined. As an example, I don't believe that there is any performance penalty for the higher level of abstraction in the BSD pmap API vs. representing the MD layer as a multi-level page table. > > I think that some of the abstractions we need are tied up in the work that > Takuya did > for SoC and some of it is in the work done by Luigi on netmap. I'd go so far > as to say > that what we should do is try to combine those two pieces of code into a set > of > low level APIs for programs to interact with high speed NICs. I'm inclined to agree although I have fairly recently changed the ifnet API for multi-queue I have received very little in the way of useful responses to my inquiries with various individuals about the interfaces exported by current cards. Based on my limited understanding of netmap as it exists now, I think that going forward netmap should develop in to a general API for safely exporting of queues to userspace, with the current limitations placed on it being solely for cards that don't support the more advanced features. I am only familiar with the documentation for Solarflare's quasi iommu and have access to an implementation of exporting queues to userspace on ixgbe cards. It appears that for a broader understanding of current NIC feature sets I will have to resort to spelunking through the network driver sources on kernel.org. This is probably reasonable when it comes to directing flows as linux is converging on a single API, but I am not aware of a similar general API for exporting queues. > The one thing most > people do not talk about is extending our socket API to do two things that I > think would > be a win for 80% of our users. If a socket, and also a kqueue, could be > pinned > to a CPU as well as a NIC queue that should improve overall bandwidth for a > large > number of our users. The API there is definitely an ioctl() and the hard > part is > doing the tying together. To do this we need to also work out our low level > story. This is clearly a useful application, perhaps the most straightforward, but I think there is a much broader set of possible uses. Cheers ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: igb/ixgbe RSS/RX queues for non-IP traffic
On Wednesday, September 07, 2011 10:52:17 am Alexander V. Chernikov wrote: > Hello list! > > (CC'in Jack Vogel since this is intel drivers/hardware specific question) > > There are some techniques for assigning network traffic to different NIC > RX queues (bound to different CPUs/cores). > The main problem for all techniques is avoiding any possible packet > reordering in single flow. > > Most obvious (and most used) are described in Microsoft NDIS driver > specification: > Hashing is done on various tuples like: > * IPv46 src/dst + TCP/UDP src/dst port for TCP/UDP > * IPv46 src/dst for general IPv46 traffic > > igb's have a bit more options like assigning selected ethertype or TCP > SYN to different queue (See section 7.1.1 of 82576EB datasheet) > ixgbe (82599) goes even more far: flow director functionality permits 8K > 'perfect match' filters allowing to select any subset in: > * vlan > * IPv46 src/dst > * L4 proto > * TCP/UDP/SCTP protocol ports > and even 'flexible 2-byte tuple anywhere in the first 64 bytes of the > packet' > > There are other possibilities to assign traffic to different queues in > ixbge like using .1q priority filed (DCB functionality) > More information can be found in sections 7.1.2 (RX queues assignment), > 7.1.2.7(Flow Director), 7.7.1 (DCB) of 82599 datasheet > > However, there are many setups where PC can be used as platform for > routing/dispatching non-IP traffic. > PPPoE server is a typical example. > > People have to do some tricks (link aggregation, non-direct ISR) to get > traffic dispatched by more than single CPU/core, but this much less > efficient. > I'm a bit curious: why some generic hashing mechanism based on something > like 'flexible 2-byte tuple anywhere in the first 64 bytes of the > packet' were not added? > It can be (at least from my point of view) easily based on (for example) > flow director functionality. > > Particularly I'm trying to figure out how can I use all this variety of > filters to get MPLS traffic split to different RX queues. > > Maybe someone can point me to the right direction? There is another thread on net@ currently talking a good bit about this. It started with a post with a patch to support the traffic steering on ixgbe adapters using sysctls. -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Adding Flow Director sysctls to ixgbe(4)
On Fri, 2011-09-09 at 13:18 +0900, Takuya ASADA wrote:
> On Sep 9, 2011, at 9:44 AM, Ben Hutchings wrote:
>
> > But it would be a lot nicer if this could be done automatically. Which
> > I believe it can - see the RFS and XPS features in Linux.
>
> Does it cooperate with hw queues and hw hashing now?
> When I saw RFS code, it was just worked with RPS.
I added support for using hardware filters ('accelerated RFS').
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: igb/ixgbe RSS/RX queues for non-IP traffic
On Wed, Sep 7, 2011 at 10:52 AM, Alexander V. Chernikov wrote: > Particularly I'm trying to figure out how can I use all this variety of > filters to get MPLS traffic split to different RX queues. I've got bad news for you on this. From Section 7.1.2.7 of the 82599 datasheet(Flow Director Filters). - IP packets are candidates for the flow director filters (meaning non-IP packets miss all filters) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
