Hello, I have some questions (I do not look to c-sources): Can the crossbow project coexist with ipqos(7ipp) ? Is the defined maximum bandwith sufficient control (compare with tokenmt(7ipp), tswtclmt(7ipp)) ? Any output from "PSARC 2006/357" ? What about crossbow - ipqos merge: - Can "zone" and "mac-address/vnic" resources be added to ipqos classifier (ipgpc(7ipp)?) (eg. unified l4/l3/l2 qos classifier) ? - Can ipgpc(7ipp) rules be compiled to hw-nic classifier (eg. link to tx/rx hw ring) ? - Can a new "ipqos marker" be created to set "mac-address/vnic" ? - Can the ipqos use "cookies" like in the crossbow project (eg. use interrupt/pooling mechanism as defined in crossbow) ? M.C> PS: Please correct link in http://www.opensolaris.org/os/project/crossbow/Docs/ This message posted from opensolaris.org
Hi,> Hello, > > I have some questions (I do not look to c-sources): > > Can the crossbow project coexist with ipqos(7ipp) ? > Is the defined maximum bandwith sufficient control (compare with tokenmt(7ipp), > tswtclmt(7ipp)) ?As per current plan, you want to use either crossbow or ipqos. Crossbow has very simple metering mechanism which processes configured bandwidth over a period of 1 tick (10msec). As soon as the configured bytes are exhausted (processed) for the particular tick, that particular traffic is no longer processed till next tick starts. The Squeue will put the Rx ring in poll mode (and will not pick any packets till next tick). Similarly, any writer trying to send packets will be blocked (if its a non blocking socket, then call will return with EAGAIN). If 10msec is too big a interval, hi res ticks can be used to maintain bandwidth over a smaller period.> Any output from "PSARC 2006/357" ?We just had a prelim review. Will have a more formal inception soon.> What about crossbow - ipqos merge:ipqos is too complex to be built in the stack itself. Hence the separation.> - Can "zone" and "mac-address/vnic" resources be added to ipqos classifier (ipg > pc(7ipp)?) (eg. unified l4/l3/l2 qos classifier) ?They can be but will require work in IPqos which is currently not planned.> - Can ipgpc(7ipp) rules be compiled to hw-nic classifier (eg. link to tx/rx hw > ring) ? > - Can a new "ipqos marker" be created to set "mac-address/vnic" ? > - Can the ipqos use "cookies" like in the crossbow project (eg. use > interrupt/pooling mechanism as defined in crossbow) ?Again, currently the scope for Crossbow project doesn''t have any of this planned. Thanks, Sunay> > M.C> > > PS: Please correct link in http://www.opensolaris.org/os/project/crossbow/Docs/Thats for pointing that out. Will fix it. -- Sunay Tripathi Sr. Staff Engineer Solaris Core Networking Technologies Sun MicroSystems Inc. Solaris Networking: http://www.opensolaris.org/os/community/networking Project Crossbow: http://www.opensolaris.org/os/project/crossbow
Hi Sunay, Why is there no QoS plan for crossbow? Was it judged too much work for the market need? A lack of QoS features will preclude adoption at some sites. Sunay Tripathi wrote:> Hi, > >>Can the crossbow project coexist with ipqos(7ipp) ? >>Is the defined maximum bandwith sufficient control (compare with tokenmt(7ipp), >>tswtclmt(7ipp)) ? > > As per current plan, you want to use either crossbow or ipqos. Crossbow has > very simple metering mechanism which processes configured bandwidth over > a period of 1 tick (10msec). As soon as the configured bytes are exhausted > (processed) for the particular tick, that particular traffic is no longer > processed till next tick starts. The Squeue will put the Rx ring in poll > mode (and will not pick any packets till next tick). Similarly, any > writer trying to send packets will be blocked (if its a non blocking > socket, then call will return with EAGAIN). > > If 10msec is too big a interval, hi res ticks can be used to maintain > bandwidth over a smaller period. > >>Any output from "PSARC 2006/357" ? > > We just had a prelim review. Will have a more formal inception soon. > >>What about crossbow - ipqos merge: > > ipqos is too complex to be built in the stack itself. Hence the separation. > >>- Can "zone" and "mac-address/vnic" resources be added to ipqos classifier (ipg >>pc(7ipp)?) (eg. unified l4/l3/l2 qos classifier) ? > > They can be but will require work in IPqos which is currently not planned. > >>- Can ipgpc(7ipp) rules be compiled to hw-nic classifier (eg. link to tx/rx hw ring) ? >>- Can a new "ipqos marker" be created to set "mac-address/vnic" ? >>- Can the ipqos use "cookies" like in the crossbow project (eg. use >>interrupt/pooling mechanism as defined in crossbow) ? > > Again, currently the scope for Crossbow project doesn''t have any of > this planned.-- -------------------------------------------------------------------------- Jeff VICTOR Sun Microsystems jeff.victor @ sun.com OS Ambassador Sr. Technical Specialist Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq --------------------------------------------------------------------------
Hello,> > Can the crossbow project coexist with ipqos(7ipp) ? > As per current plan, you want to use either crossbow > or ipqos.:-(> Crossbow has > very simple metering mechanism which processes > configured bandwidth over > a period of 1 tick (10msec).What about asymmetric rx/tx bandwidth (accommodate to ADSL) ? M.C> This message posted from opensolaris.org
Hi Jeff, The reason is that Crossbow does B/W control very differently. I belive the various metering RFCs including 2697, 2698, 2859 etc were specifically designed where the ipqos module had no control over the packet arrival (by means of interrupt and various application threads doing write). Crossbow on the other hand can control the rate of packet arrival in the system itself (by switching the VNIC to polling mode when necessary and putting application threads to sleep or returning eagain for non-blocking). Implementing the RFCs mentioned above with Crossbow is not a natural fit. We haven''t really investigated this much, but trying to integrate ipqos with Crossbow is not a natural fit. Also, ipqos is hard to administor and has heavy performance penalties because of the nature of beast. But then it is able to provide some more functionality like different metering algorithms, doing flows based on layer 7 etc that Crossbow can not do. So our plan is to provide a simple model for bandwidth control and virtualization via Crossbow that will satisfy 90% of the needs. We do have plans to take a closer look later on what needs to be done to ipqos. Meanwhile we would love to hear from some ipqos users on what they are using, what works and what doesn''t and where Crossbow falls short. Hope this helps. Sunay> Hi Sunay, > > Why is there no QoS plan for crossbow? Was it judged too much work for the market > need? A lack of QoS features will preclude adoption at some sites. > > Sunay Tripathi wrote: > > Hi, > > > >>Can the crossbow project coexist with ipqos(7ipp) ? > >>Is the defined maximum bandwith sufficient control (compare with tokenmt(7ipp), > >>tswtclmt(7ipp)) ? > > > > As per current plan, you want to use either crossbow or ipqos. Crossbow has > > very simple metering mechanism which processes configured bandwidth over > > a period of 1 tick (10msec). As soon as the configured bytes are exhausted > > (processed) for the particular tick, that particular traffic is no longer > > processed till next tick starts. The Squeue will put the Rx ring in poll > > mode (and will not pick any packets till next tick). Similarly, any > > writer trying to send packets will be blocked (if its a non blocking > > socket, then call will return with EAGAIN). > > > > If 10msec is too big a interval, hi res ticks can be used to maintain > > bandwidth over a smaller period. > > > >>Any output from "PSARC 2006/357" ? > > > > We just had a prelim review. Will have a more formal inception soon. > > > >>What about crossbow - ipqos merge: > > > > ipqos is too complex to be built in the stack itself. Hence the separation. > > > >>- Can "zone" and "mac-address/vnic" resources be added to ipqos classifier (ipg > >>pc(7ipp)?) (eg. unified l4/l3/l2 qos classifier) ? > > > > They can be but will require work in IPqos which is currently not planned. > > > >>- Can ipgpc(7ipp) rules be compiled to hw-nic classifier (eg. link to tx/rx hw ring) ? > >>- Can a new "ipqos marker" be created to set "mac-address/vnic" ? > >>- Can the ipqos use "cookies" like in the crossbow project (eg. use > >>interrupt/pooling mechanism as defined in crossbow) ? > > > > Again, currently the scope for Crossbow project doesn''t have any of > > this planned. > > -- > -------------------------------------------------------------------------- > Jeff VICTOR Sun Microsystems jeff.victor @ sun.com > OS Ambassador Sr. Technical Specialist > Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq > -------------------------------------------------------------------------- >-- Sunay Tripathi Sr. Staff Engineer Solaris Core Networking Technologies Sun MicroSystems Inc. Solaris Networking: http://www.opensolaris.org/os/community/networking Project Crossbow: http://www.opensolaris.org/os/project/crossbow
Hi Martin,> Hello, > > > > Can the crossbow project coexist with ipqos(7ipp) ? > > As per current plan, you want to use either crossbow > > or ipqos. > :-(See my email to Jeff. Can you provide some more insight as to how you use ipqos including the various metering algorithms to your advantage. Its important for us to understand that and see what can be incorporated into Crossbow.> > > Crossbow has > > very simple metering mechanism which processes > > configured bandwidth over > > a period of 1 tick (10msec). > > What about asymmetric rx/tx bandwidth (accommodate to ADSL) ?Its definitely possible architecturally. Lets see how we can work this into our administrative interfaces. Thanks, Sunay> > M.C>-- Sunay Tripathi Sr. Staff Engineer Solaris Core Networking Technologies Sun MicroSystems Inc. Solaris Networking: http://www.opensolaris.org/os/community/networking Project Crossbow: http://www.opensolaris.org/os/project/crossbow