Re: Re: intel checksum offload
Hi, I'm also curious about why the CSUM_IP was removed in all the intel NICs. Although this thread is very old, I still need the answer because IP checksum offload is actually supported in intel's datasheet. Thanks! 2012-04-14 beezarliu 发件人： YongHyeon PYUN 发送时间： 2011-09-18 04:58:10 收件人： Hooman Fazaeli 抄送： jfv; freebsd-hackers 主题： Re: intel checksum offload On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: > Hi list, > > The data sheet for intel 82576 advertises IP TX/RX checksum offload > but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean that > driver (and chip) do not support IP TX checksum offload or the support for > TX is not yet included in the driver? After reading this mail, I checked em(4)/lem(4) code and noticed these drivers removed CSUM_IP capability as well. igb(4) didn't support CSUM_IP from day 1 but em(4)/lem(4) used to take advantage of IP checksum offloading capability. Given that these drivers share many code with Linux, Jack may know the details and why IP checksum offloading code was removed. Note, Linux does not use IP checksum offloading so I guess this could be oversight in shared code. BTW, hackers may not be right ML to post this kind of post. CCed to jfv@, the driver maintainer. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
Hi, On Mon, Sep 19, 2011 at 12:59 PM, YongHyeon PYUN wrote: > On Mon, Sep 19, 2011 at 10:17:22AM -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Mon, Sep 19, 2011 at 5:28 AM, Adrian Chadd wrote: >> > Arnaud (and others), >> > >> > Liaising with vendors is not an easy task. The reason why Intel (and >> > other vendors) don't supply detailed history and reasoning for their >> > development efforts is that their engineers are likely tasked with >> > "making it work" versus "writing lots of stuff down for public >> > release." In some instances, the vendor support of FreeBSD (and "free" >> > open source in general) is done as a side-project by some of the >> > engineers inside the company. >> > >> > So in this case, you may find that Jack and the other engineers at >> > Intel just don't have the time or resources to dedicate the kinds of >> > feedback and support you seem to be after. He and others likely have a >> > huge set of tasks to do at work and none of them officially include >> > "support FreeBSD/Linux developers by providing detailed feedback and >> > assistance." So whenever Jack pops up to help out, he's likely doing >> > it in his spare time. :-) >> > >> Yes, and he seems to really like to waste his spare time by repeating >> me for two months to increase `kern.ipc.nmbclusters' to fix issue I >> was seeing, when the code was clearly buggy, even when I sent him >> patchs fixing issues. >> > > If you think you encountered a driver bug, could you share it with > us? I didn't closely follow em(4)/lem(4)/igb(4) changes for a long > time so I'm not sure whether I can come up with reasonable fix for > the issue but I may be able to help you. > They ended up being fixed, thanks :-) Now, up until next week, we were struggle on the mbuf corruption I reported on freebsd-net@, but I do not think it is a driver issue per-se. - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
On Mon, Sep 19, 2011 at 10:17:22AM -0400, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 19, 2011 at 5:28 AM, Adrian Chadd wrote: > > Arnaud (and others), > > > > Liaising with vendors is not an easy task. The reason why Intel (and > > other vendors) don't supply detailed history and reasoning for their > > development efforts is that their engineers are likely tasked with > > "making it work" versus "writing lots of stuff down for public > > release." In some instances, the vendor support of FreeBSD (and "free" > > open source in general) is done as a side-project by some of the > > engineers inside the company. > > > > So in this case, you may find that Jack and the other engineers at > > Intel just don't have the time or resources to dedicate the kinds of > > feedback and support you seem to be after. He and others likely have a > > huge set of tasks to do at work and none of them officially include > > "support FreeBSD/Linux developers by providing detailed feedback and > > assistance." So whenever Jack pops up to help out, he's likely doing > > it in his spare time. :-) > > > Yes, and he seems to really like to waste his spare time by repeating > me for two months to increase `kern.ipc.nmbclusters' to fix issue I > was seeing, when the code was clearly buggy, even when I sent him > patchs fixing issues. > If you think you encountered a driver bug, could you share it with us? I didn't closely follow em(4)/lem(4)/igb(4) changes for a long time so I'm not sure whether I can come up with reasonable fix for the issue but I may be able to help you. > That's sure a very efficient way of managing time. > > - Arnaud > > > Developers can and will disable or remove functionality which is > > problematic because they don't have the time or resources to support > > it. Users may wish to turn on unsupported features and then will > > complain loudly when they don't work; even giving up and moving to > > another piece of equipment because of perceived issues. I agree that > > it would be nice if the developers included _all_ features, > > unsupported or not, so that developers can choose to work on them if > > they wish. It however is a trade-off between trying to provide > > developers with more useful things to tinker with and not increasing > > support load from users (and other developers) who seek to use > > incomplete features. > > > > I hope this helps. > > > > > > Adrian > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
Hi, On Mon, Sep 19, 2011 at 5:28 AM, Adrian Chadd wrote: > Arnaud (and others), > > Liaising with vendors is not an easy task. The reason why Intel (and > other vendors) don't supply detailed history and reasoning for their > development efforts is that their engineers are likely tasked with > "making it work" versus "writing lots of stuff down for public > release." In some instances, the vendor support of FreeBSD (and "free" > open source in general) is done as a side-project by some of the > engineers inside the company. > > So in this case, you may find that Jack and the other engineers at > Intel just don't have the time or resources to dedicate the kinds of > feedback and support you seem to be after. He and others likely have a > huge set of tasks to do at work and none of them officially include > "support FreeBSD/Linux developers by providing detailed feedback and > assistance." So whenever Jack pops up to help out, he's likely doing > it in his spare time. :-) > Yes, and he seems to really like to waste his spare time by repeating me for two months to increase `kern.ipc.nmbclusters' to fix issue I was seeing, when the code was clearly buggy, even when I sent him patchs fixing issues. That's sure a very efficient way of managing time. - Arnaud > Developers can and will disable or remove functionality which is > problematic because they don't have the time or resources to support > it. Users may wish to turn on unsupported features and then will > complain loudly when they don't work; even giving up and moving to > another piece of equipment because of perceived issues. I agree that > it would be nice if the developers included _all_ features, > unsupported or not, so that developers can choose to work on them if > they wish. It however is a trade-off between trying to provide > developers with more useful things to tinker with and not increasing > support load from users (and other developers) who seek to use > incomplete features. > > I hope this helps. > > > Adrian > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
On Sunday, September 18, 2011 10:48:32 pm Arnaud Lacombe wrote: > As the PCI spec is not public, I've not been able to find out from the > few public datasheet how the PCI MSI-X capability field is first > programmed. I'd assume that the BIOS is using the data in the NVM to > program it at power up. "PCI System Architecture" is quite public at Amazon. It's not the spec, but it will certainly give you enough info to understand MSI and it covers the question you are asking well enough. The MSI config registers are not touched by the BIOS at all (at least not in a standard way). It is the responsibility of the device to setup the read-only fields in the MSI and MSI-X config registers on reset. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
On Sun, Sep 18, 2011 at 7:48 PM, Arnaud Lacombe wrote: > Hi, > > On Sun, Sep 18, 2011 at 10:01 PM, Luigi Rizzo wrote: > > On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote: > >> Hi, > >> > >> On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo > wrote: > >> > On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: > >> >> Hi, > >> >> > >> >> On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN > wrote: > >> >> > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: > >> >> >> Hi list, > >> >> >> > >> >> >> The data sheet for intel 82576 advertises IP TX/RX checksum > offload > >> >> >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this > mean that > >> >> >> driver (and chip) do not support IP TX checksum offload or the > support for > >> >> >> TX is not yet included in the driver? > >> > ... > >> >> This is slightly off-topic, but still.. > >> >> > >> >> FWIW, I'm not really impressed by what chips claim to support vs. > what > >> >> has been implemented in the driver. As per the product brief, the > >> > ... > >> >> [0]: the commit message say "performance was not good", but it is not > >> >> the driver's developer to decide whether or not a feature is good or > >> >> not. The developer's job is to implement the chip capabilities, and > >> >> let it to the user to enable or disable the capabilities. At best, > the > >> >> developer can decide whether or not to enable the feature by default. > >> > > >> > actually, this is a perfect example where the developer has done the > >> > right thing: implemented the feature, verified that performance is > bad, > >> > hence presumably removed support for the feature from the code (which > also > >> > means that the normal code path will run faster because there are no > >> > run-time decisions to be made). > >> > > >> > "optional" features are often costly even when disabled. > >> > > >> I forgot to mention that in this case, the code full of > >> EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with > >> the multiqueue's architecture. The only thing removed is a conditional > >> and an assignation in the driver's attachment which was enabling the > >> feature, ie. the cost you point out is still paid today, without any > >> benefit. > > > > the above suggests that you have a wonderful opportunity: with just > > a little bit of time and effort you should be able to complete/re-enable > > the missing code, run tests that you believe significant (given > > your statement below) and prove or disprove the comment about > > performance. > > > Which I did about a week ago, to finally discover that the NIC only > had only 3 MSI-X vectors configured in its EEPROM[0], and thus the > MSI-X PCI capability field ends up also with being assigned with those > 3 vectors. However, the 82574 datasheet clearly say that up-to 5 > vector can be configured, but I obviously did not find the magic trick > to make it so. Maybe I'll find some time and try to reprogram the > EEPROM. Beside that, it was clear that the old multiqueue did not > support only 3 vector being available and thus fell back on MSI. It is > not clear in jfv@'s comment whether he really tested multiqueue, or > did he test the fall-back MSI mode. > > As the PCI spec is not public, I've not been able to find out from the > few public datasheet how the PCI MSI-X capability field is first > programmed. I'd assume that the BIOS is using the data in the NVM to > program it at power up. > > - Arnaud > > [0]: at least, the MSI_X_NUM field of the NVM at offset 0x1b is 2, > thus 3 vectors. > I give answers to those who treat me with respect, I view them as collaborators, we improve the drivers for everyone's benefit, rather than jumping in to throw a critical remark here, a negative innuendo there... If you notice, the Linux driver did not enable multiqueue on the hardware either, so do you think a whole department of software engineers backed by the hardware engineers who designed the damn thing might have had a reason? IN FACT, as I have a bit more freedom with FreeBSD, I went ahead and tried it for a while just because I could, implementing the code was not difficult. Over time however that code proved to be a source of instability and thus was disabled. I have heard a rumor that the Linux crew may actually be trying a second time to make it work, and that might give me cause to look at it again too, but its not clear if I'll have time with other priorities. Jack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
Arnaud (and others), Liaising with vendors is not an easy task. The reason why Intel (and other vendors) don't supply detailed history and reasoning for their development efforts is that their engineers are likely tasked with "making it work" versus "writing lots of stuff down for public release." In some instances, the vendor support of FreeBSD (and "free" open source in general) is done as a side-project by some of the engineers inside the company. So in this case, you may find that Jack and the other engineers at Intel just don't have the time or resources to dedicate the kinds of feedback and support you seem to be after. He and others likely have a huge set of tasks to do at work and none of them officially include "support FreeBSD/Linux developers by providing detailed feedback and assistance." So whenever Jack pops up to help out, he's likely doing it in his spare time. :-) Developers can and will disable or remove functionality which is problematic because they don't have the time or resources to support it. Users may wish to turn on unsupported features and then will complain loudly when they don't work; even giving up and moving to another piece of equipment because of perceived issues. I agree that it would be nice if the developers included _all_ features, unsupported or not, so that developers can choose to work on them if they wish. It however is a trade-off between trying to provide developers with more useful things to tinker with and not increasing support load from users (and other developers) who seek to use incomplete features. I hope this helps. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
It is interesting that how a thread goes off topic! Anyway, I will appreciate if folks, especially Jack, provide a firm comment on the original question: Does intel chips (specifically 82576) support IP TX checksum offload? If so, why the driver does not support it? On 9/19/2011 8:59 AM, Jack Vogel wrote: On Sun, Sep 18, 2011 at 7:48 PM, Arnaud Lacombe mailto:lacom...@gmail.com>> wrote: Hi, On Sun, Sep 18, 2011 at 10:01 PM, Luigi Rizzo mailto:ri...@iet.unipi.it>> wrote: > On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo mailto:ri...@iet.unipi.it>> wrote: >> > On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: >> >> Hi, >> >> >> >> On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN mailto:pyu...@gmail.com>> wrote: >> >> > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: >> >> >> Hi list, >> >> >> >> >> >> The data sheet for intel 82576 advertises IP TX/RX checksum offload >> >> >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean that >> >> >> driver (and chip) do not support IP TX checksum offload or the support for >> >> >> TX is not yet included in the driver? >> > ... >> >> This is slightly off-topic, but still.. >> >> >> >> FWIW, I'm not really impressed by what chips claim to support vs. what >> >> has been implemented in the driver. As per the product brief, the >> > ... >> >> [0]: the commit message say "performance was not good", but it is not >> >> the driver's developer to decide whether or not a feature is good or >> >> not. The developer's job is to implement the chip capabilities, and >> >> let it to the user to enable or disable the capabilities. At best, the >> >> developer can decide whether or not to enable the feature by default. >> > >> > actually, this is a perfect example where the developer has done the >> > right thing: implemented the feature, verified that performance is bad, >> > hence presumably removed support for the feature from the code (which also >> > means that the normal code path will run faster because there are no >> > run-time decisions to be made). >> > >> > "optional" features are often costly even when disabled. >> > >> I forgot to mention that in this case, the code full of >> EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with >> the multiqueue's architecture. The only thing removed is a conditional >> and an assignation in the driver's attachment which was enabling the >> feature, ie. the cost you point out is still paid today, without any >> benefit. > > the above suggests that you have a wonderful opportunity: with just > a little bit of time and effort you should be able to complete/re-enable > the missing code, run tests that you believe significant (given > your statement below) and prove or disprove the comment about > performance. > Which I did about a week ago, to finally discover that the NIC only had only 3 MSI-X vectors configured in its EEPROM[0], and thus the MSI-X PCI capability field ends up also with being assigned with those 3 vectors. However, the 82574 datasheet clearly say that up-to 5 vector can be configured, but I obviously did not find the magic trick to make it so. Maybe I'll find some time and try to reprogram the EEPROM. Beside that, it was clear that the old multiqueue did not support only 3 vector being available and thus fell back on MSI. It is not clear in jfv@'s comment whether he really tested multiqueue, or did he test the fall-back MSI mode. As the PCI spec is not public, I've not been able to find out from the few public datasheet how the PCI MSI-X capability field is first programmed. I'd assume that the BIOS is using the data in the NVM to program it at power up. - Arnaud [0]: at least, the MSI_X_NUM field of the NVM at offset 0x1b is 2, thus 3 vectors. I give answers to those who treat me with respect, I view them as collaborators, we improve the drivers for everyone's benefit, rather than jumping in to throw a critical remark here, a negative innuendo there... If you notice, the Linux driver did not enable multiqueue on the hardware either, so do you think a whole department of software engineers backed by the hardware engineers who designed the damn thing might have had a reason? IN FACT, as I have a bit more freedom with FreeBSD, I went ahead and tried it for a while just because I could, implementing the code was not difficult. Over time however that code proved to be a source of instability and thus was disabled. I have heard a rumor that the Linux crew may actually be trying a second time to make it work, and that might give me cause to look at it again too, but its not clear if I'll have time with
Re: intel checksum offload
Hi, On Mon, Sep 19, 2011 at 12:29 AM, Jack Vogel wrote: > [...] > If you notice, the Linux driver did not enable multiqueue on the hardware > either, so do you think a whole department of software engineers backed > by the hardware engineers who designed the damn thing might have had > a reason? > Let's find out :-) In the mean time, as a hacker, I'd be interested to know why the NVM ships with MSI_X_NUM == 2 at offset 0x1b when the datasheet say it does support up value to 4 ? This might be as simple as "the hardware needs special wiring to support 5 vectors.", or whatever... > IN FACT, as I have a bit more freedom with FreeBSD, I went ahead and > tried it for a while just because I could, implementing the code was not > difficult. Over time however that code proved to be a source of instability > and thus was disabled. > It would be interesting for the records to have this information public, especially the kind of instability seen. > I have heard a rumor that the Linux crew may actually be trying a second > time to make it work, and that might give me cause to look at it again too, > but its not clear if I'll have time with other priorities. > ack. Now, what about header-split support in em(4) ? Thanks, - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
Hi, On Sun, Sep 18, 2011 at 10:01 PM, Luigi Rizzo wrote: > On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo wrote: >> > On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: >> >> Hi, >> >> >> >> On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN wrote: >> >> > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: >> >> >> Hi list, >> >> >> >> >> >> The data sheet for intel 82576 advertises IP TX/RX checksum offload >> >> >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this >> >> >> mean that >> >> >> driver (and chip) do not support IP TX checksum offload or the support >> >> >> for >> >> >> TX is not yet included in the driver? >> > ... >> >> This is slightly off-topic, but still.. >> >> >> >> FWIW, I'm not really impressed by what chips claim to support vs. what >> >> has been implemented in the driver. As per the product brief, the >> > ... >> >> [0]: the commit message say "performance was not good", but it is not >> >> the driver's developer to decide whether or not a feature is good or >> >> not. The developer's job is to implement the chip capabilities, and >> >> let it to the user to enable or disable the capabilities. At best, the >> >> developer can decide whether or not to enable the feature by default. >> > >> > actually, this is a perfect example where the developer has done the >> > right thing: implemented the feature, verified that performance is bad, >> > hence presumably removed support for the feature from the code (which also >> > means that the normal code path will run faster because there are no >> > run-time decisions to be made). >> > >> > "optional" features are often costly even when disabled. >> > >> I forgot to mention that in this case, the code full of >> EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with >> the multiqueue's architecture. The only thing removed is a conditional >> and an assignation in the driver's attachment which was enabling the >> feature, ie. the cost you point out is still paid today, without any >> benefit. > > the above suggests that you have a wonderful opportunity: with just > a little bit of time and effort you should be able to complete/re-enable > the missing code, run tests that you believe significant (given > your statement below) and prove or disprove the comment about > performance. > Which I did about a week ago, to finally discover that the NIC only had only 3 MSI-X vectors configured in its EEPROM[0], and thus the MSI-X PCI capability field ends up also with being assigned with those 3 vectors. However, the 82574 datasheet clearly say that up-to 5 vector can be configured, but I obviously did not find the magic trick to make it so. Maybe I'll find some time and try to reprogram the EEPROM. Beside that, it was clear that the old multiqueue did not support only 3 vector being available and thus fell back on MSI. It is not clear in jfv@'s comment whether he really tested multiqueue, or did he test the fall-back MSI mode. As the PCI spec is not public, I've not been able to find out from the few public datasheet how the PCI MSI-X capability field is first programmed. I'd assume that the BIOS is using the data in the NVM to program it at power up. - Arnaud [0]: at least, the MSI_X_NUM field of the NVM at offset 0x1b is 2, thus 3 vectors. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
.. and believe me, lots of people will appreciate it if you can verify/diagnose issues. :) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote: > Hi, > > On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo wrote: > > On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: > >> Hi, > >> > >> On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN wrote: > >> > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: > >> >> Hi list, > >> >> > >> >> The data sheet for intel 82576 advertises IP TX/RX checksum offload > >> >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean > >> >> that > >> >> driver (and chip) do not support IP TX checksum offload or the support > >> >> for > >> >> TX is not yet included in the driver? > > ... > >> This is slightly off-topic, but still.. > >> > >> FWIW, I'm not really impressed by what chips claim to support vs. what > >> has been implemented in the driver. As per the product brief, the > > ... > >> [0]: the commit message say "performance was not good", but it is not > >> the driver's developer to decide whether or not a feature is good or > >> not. The developer's job is to implement the chip capabilities, and > >> let it to the user to enable or disable the capabilities. At best, the > >> developer can decide whether or not to enable the feature by default. > > > > actually, this is a perfect example where the developer has done the > > right thing: implemented the feature, verified that performance is bad, > > hence presumably removed support for the feature from the code (which also > > means that the normal code path will run faster because there are no > > run-time decisions to be made). > > > > "optional" features are often costly even when disabled. > > > I forgot to mention that in this case, the code full of > EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with > the multiqueue's architecture. The only thing removed is a conditional > and an assignation in the driver's attachment which was enabling the > feature, ie. the cost you point out is still paid today, without any > benefit. the above suggests that you have a wonderful opportunity: with just a little bit of time and effort you should be able to complete/re-enable the missing code, run tests that you believe significant (given your statement below) and prove or disprove the comment about performance. cheers luigi > > Now I might also openly question the test method used by the folks at > Intel, just seeing how much issue I've had with the driver (I still > have for some, even if not driver related), which have not been > reproduced there. > > Finally, when someone say "performance are better that way", the first > thing I'd be tempted to ask is: "What is your test ? How did you > collects the numbers ? How did you reach the conclusion ?". None of > this stuff is public. > regards, > - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
Hi, On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo wrote: > On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN wrote: >> > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: >> >> Hi list, >> >> >> >> The data sheet for intel 82576 advertises IP TX/RX checksum offload >> >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean >> >> that >> >> driver (and chip) do not support IP TX checksum offload or the support for >> >> TX is not yet included in the driver? > ... >> This is slightly off-topic, but still.. >> >> FWIW, I'm not really impressed by what chips claim to support vs. what >> has been implemented in the driver. As per the product brief, the > ... >> [0]: the commit message say "performance was not good", but it is not >> the driver's developer to decide whether or not a feature is good or >> not. The developer's job is to implement the chip capabilities, and >> let it to the user to enable or disable the capabilities. At best, the >> developer can decide whether or not to enable the feature by default. > > actually, this is a perfect example where the developer has done the > right thing: implemented the feature, verified that performance is bad, > hence presumably removed support for the feature from the code (which also > means that the normal code path will run faster because there are no > run-time decisions to be made). > > "optional" features are often costly even when disabled. > I forgot to mention that in this case, the code full of EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with the multiqueue's architecture. The only thing removed is a conditional and an assignation in the driver's attachment which was enabling the feature, ie. the cost you point out is still paid today, without any benefit. Now I might also openly question the test method used by the folks at Intel, just seeing how much issue I've had with the driver (I still have for some, even if not driver related), which have not been reproduced there. Finally, when someone say "performance are better that way", the first thing I'd be tempted to ask is: "What is your test ? How did you collects the numbers ? How did you reach the conclusion ?". None of this stuff is public. regards, - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: > Hi, > > On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN wrote: > > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: > >> Hi list, > >> > >> The data sheet for intel 82576 advertises IP TX/RX checksum offload > >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean > >> that > >> driver (and chip) do not support IP TX checksum offload or the support for > >> TX is not yet included in the driver? ... > This is slightly off-topic, but still.. > > FWIW, I'm not really impressed by what chips claim to support vs. what > has been implemented in the driver. As per the product brief, the ... > [0]: the commit message say "performance was not good", but it is not > the driver's developer to decide whether or not a feature is good or > not. The developer's job is to implement the chip capabilities, and > let it to the user to enable or disable the capabilities. At best, the > developer can decide whether or not to enable the feature by default. actually, this is a perfect example where the developer has done the right thing: implemented the feature, verified that performance is bad, hence presumably removed support for the feature from the code (which also means that the normal code path will run faster because there are no run-time decisions to be made). "optional" features are often costly even when disabled. cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
Hi, On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN wrote: > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: >> Hi list, >> >> The data sheet for intel 82576 advertises IP TX/RX checksum offload >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean that >> driver (and chip) do not support IP TX checksum offload or the support for >> TX is not yet included in the driver? > > After reading this mail, I checked em(4)/lem(4) code and noticed > these drivers removed CSUM_IP capability as well. igb(4) didn't > support CSUM_IP from day 1 but em(4)/lem(4) used to take advantage > of IP checksum offloading capability. > Given that these drivers share many code with Linux, Jack may know > the details and why IP checksum offloading code was removed. Note, > Linux does not use IP checksum offloading so I guess this could be > oversight in shared code. > > BTW, hackers may not be right ML to post this kind of post. > CCed to jfv@, the driver maintainer. > This is slightly off-topic, but still.. FWIW, I'm not really impressed by what chips claim to support vs. what has been implemented in the driver. As per the product brief, the 82574 supports multiqueue (at least should support up to 5 MSI-X vectors, 2 RX and 2 TX), but this support was removed from em(4) in mid-2010[0]. Also, the 82571 and the 82574 should also support header split, but this is currently only implemented in igb(4), not em(4). - Arnaud [0]: the commit message say "performance was not good", but it is not the driver's developer to decide whether or not a feature is good or not. The developer's job is to implement the chip capabilities, and let it to the user to enable or disable the capabilities. At best, the developer can decide whether or not to enable the feature by default. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: intel checksum offload
On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: > Hi list, > > The data sheet for intel 82576 advertises IP TX/RX checksum offload > but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean that > driver (and chip) do not support IP TX checksum offload or the support for > TX is not yet included in the driver? After reading this mail, I checked em(4)/lem(4) code and noticed these drivers removed CSUM_IP capability as well. igb(4) didn't support CSUM_IP from day 1 but em(4)/lem(4) used to take advantage of IP checksum offloading capability. Given that these drivers share many code with Linux, Jack may know the details and why IP checksum offloading code was removed. Note, Linux does not use IP checksum offloading so I guess this could be oversight in shared code. BTW, hackers may not be right ML to post this kind of post. CCed to jfv@, the driver maintainer. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
